Re: Doc: Reorganize music functions material. (issue970044)
Reviewers: carl.d.sorensen_gmail.com, Neil Puttock,
http://codereview.appspot.com/970044/diff/1/2
File Documentation/extending/programming-interface.itely (left):
http://codereview.appspot.com/970044/diff/1/2#oldcode38
Documentation/extending/programming-interface.itely:38: * Music function
syntax::
On 2010/04/26 14:37:56, Carl wrote:
I am not in favor of eliminating Music function syntax in
Extending. This should be a complete discussion of Music
function syntax, which is more general than the syntax for
simple substitution functions.
Okay. That makes me want to put "Simple substitution
functions" back, but if I do that, is it better to copy the
analagous node verbatim from the NR or to have the whole
node be a stub linking to the NR?
http://codereview.appspot.com/970044/diff/1/3
File Documentation/notation/changing-defaults.itely (right):
http://codereview.appspot.com/970044/diff/1/3#newcode3641
Documentation/notation/changing-defaults.itely:3641: @ref{Music function
type predicates}.
On 2010/04/28 21:42:05, Neil Puttock wrote:
There's a danger here that users might think these are
the only type predicates allowed.
The list's only complete in so far as type-p-name-alist
documents predicates used internally for music functions
and properties.
There aren't that many other predicates out there (see
http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00713.html).
And I'm happy to add the remaining ones to the alist if
that will justify using the word "complete". (:
You also proposed a clever way to prevent labeling failed
type checks as "unknown" in the error message, which I'll
definitely add to the next patch set
(http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00725.html).
I'd like to do both.
Description:
Doc: Reorganize music functions material.
* Remove nodes from Extending that are covered in
Notation:
2.1.1 Music function syntax
2.1.2 Simple substitution functions
* In Extending 2.1, move `Void functions' to end
of section, so `Functions without arguments'
comes first.
* Use a consistent indentation format for music
functions.
* Make some minor formatting/wording changes.
* Create type-predicates-doc-string to document
type-p-name-alist automatically.
* Add notation appendix
`Music function type predicates' to include
type-predicates-doc-string.
Please review this at http://codereview.appspot.com/970044/show
Affected files:
M Documentation/extending/programming-interface.itely
M Documentation/notation/changing-defaults.itely
M Documentation/notation/notation-appendices.itely
M scm/c++.scm
A scm/document-type-predicates.scm
M scm/documentation-generate.scm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overriding tagline in a custom init file?
-Eluze wrote: > > > Reinhold Kainhofer wrote: >> >> >> So, do you have any idea how I can override the header and paper blocks >> in a >> global init file? >> >> > i have copied the whole init.ly to myInit.ly and then added *\include > "myPaper.ly"* right after the \maininput line (nr. 25 in version 2.13.18) > and then invoked lilypond with --init=… > this raises the question why there is no such option, enabling to setup a user specific environment or style without having to manipulate this crucial file (and to adapt it for each new version). alternatively this option could be called --user thanks for considering this enhancement! -- View this message in context: http://old.nabble.com/Overriding-tagline-in-a-custom-init-file--tp28379733p28398673.html Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overriding tagline in a custom init file?
Am Donnerstag, 29. April 2010 12:01:14 schrieb -Eluze: > -Eluze wrote: > > Reinhold Kainhofer wrote: > >> So, do you have any idea how I can override the header and paper blocks > >> in a > >> global init file? > > > > i have copied the whole init.ly to myInit.ly and then added *\include > > "myPaper.ly"* right after the \maininput line (nr. 25 in version 2.13.18) > > and then invoked lilypond with --init=… > > this raises the question why there is no such option, enabling to setup a > user specific environment or style without having to manipulate this > crucial file (and to adapt it for each new version). Absolutely! It would also make lilypond-book much simpler, since currently the book preamble is added to all included .ly files. This looks awful if you click on an image to get the LilyPond file! AFAICS, "all" that needs to be done is to -) add a new option to lilypond e.g. -duser-init=settings.ily -) in init.ly include that file (if the option is given) right before \maininput In principle, all steps are easy (adding a command line option, checking for existence of command line option, including a file). The problem is the combination: The \include has to be done conditionally, and the check for the command line option has to be done in Scheme. This means that the include also has to be done in Scheme... Unfortunately, the processing of \include in a lilypond file is already done by the parser, so I don't know of any way to properly include a file using Scheme... I have tried: #(if (ly:get-option 'user-init) (display (format "\\include \"~a\"" (ly:get-option 'user-init))) (ly:parser-parse-string parser (format "\\include \"~a\"" (ly:get-option 'user-init \maininput But this does not seem to have any effect: It includes the file (since a syntax error in the included file causes lilypond to fail), but the settings (header block) are not used... Cheers, Reionhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
David Kastrup:
> Graham Percival writes:
...
> And what if you see \chordmode { c,4:1/c c g,:1/g c } in the input
> (which is basically how you put bass notes in now if you really must)?
...
For the simple chords c\maj c\dim c\maj7 etc. could suffice.
For more complex chords one could extend the syntax to .
Regards,
/Karl Hammar
-
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On Thu, Apr 29, 2010 at 01:33:42PM +0200, Karl Hammar wrote:
> David Kastrup:
> > Graham Percival writes:
> ...
> > And what if you see \chordmode { c,4:1/c c g,:1/g c } in the input
> > (which is basically how you put bass notes in now if you really must)?
> ...
>
> For the simple chords c\maj c\dim c\maj7 etc. could suffice.
> For more complex chords one could extend the syntax to .
That's a very interesting idea! Durations need to be specified
outside the chord, of course, so that's not a concern.
OTOH, what about doing something like this:
c\maj
c\dim
c\chord #'(1 4 5)
c\chord #'(1 3 5 7 11)
If somebody used a lot of special chords, they could define their
own identifiers to replace the \chord functions.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On Thu, Apr 29, 2010 at 12:27 AM, Carl Sorensen wrote:
> But I think we could use ; in LilyPond, even though it's used for comments
> in Scheme, because the ; inside a scheme function aren't interpreted by the
> LilyPond parser, IIUC.
I like ';' very much (mostly because it feels familiar when you're
used to ':' ).
Speaking of which, I often wished we had a cool shortcut for writing
repeats using a postfix syntax, e.g.
{ large music expression here };4
instead of
\repeat unfold 4 { large music expression }
Yes I know: a) that's off-topic b) this will wait until GLISS starts.
-- As should this whole discussion IMO: may I take this as an
opportunity to remind you guys that there's a whole new ML for stuff
like that? http://lists.lilynet.net/syntax/
Cheers,
Valentin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
> > I like this > c\chord #'(1 3 5 7 11) I like this too. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Doc: Clarify \relative inside \repeat issue.
On 4/29/10 1:42 AM, "Mark Polesky" wrote:
> Carl,
> you didn't "reply to all", but here's my response anyway:
Oh, I'm sorry. I didn't mean to not reply to all. Thanks for covering for
me.
> - Mark
>
>
> Carl Sorensen wrote:
>> I disagree with the idea that the simplest solution is to
>> move the \relative outside the \repeat.
>
> Well, I disagree too, but the wording currently in the
> docs is even stronger:
>
> The correct way is to reverse the \repeat and \relative
> commands...
>
> -- AU 1.4 Common errors * An extra staff appears
>
>
>> This changes the music.
>
> Good point.
>
>
>> I think the simplest solution is to explicitly declare the
>> Voice:
>>
>> \context Voice {
>> \repeat unfold 2 {
>> \relative c' {
>>c2 d
>> }
>> }
>> }
>
> Nice. But wouldn't the code below be just as good? It
> would prevent an extra level of {...}, along with the
> additional indentation:
>
> \repeat unfold 2 \context Voice {
> \relative c' {
> c d
> }
> }
Personally, I think that it's better to put the \context Voice outside, but
this way works as well.
If you want to use the minumum number of { and indentation levels, you can
write
\context Voice \repeat unfold 2 \relative c' { c2 d }
or
\context Voice \repeat unfold 2 \relative c' {
c2 d
}
but back when the GDP was established the LilyPond format rules said we
needed to use { } even if it wasn't required. I couldn't find this rule in
section 3.4.3 of Contributing, so maybe it's gone away.
>
>
>> Perhaps we need a (sub)section in Notation on implicit
>> Staff and Voice creation that explains the LilyPond
>> constructs that cause implicit Staff creation so that
>> users can know what to look for.
>
> What about
> AU 1.4 Common errors * An extra staff appears
> ?
Perfect!
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Doc: Clarify \relative inside \repeat issue.
Sending to list for completeness.
On 4/28/10 12:39 AM, "Mark Polesky" wrote:
> It struck me that there are more options for dealing with
> the "\relative inside \repeat" issue. Can someone look over
> this to make sure I'm not doing anything sacrililygious?
In my opinion, the tone of your addition is more "Learning Manual" than
"Notation Reference".
I disagree with the idea that the simplest solution is to move the \relative
outside the \repeat. This changes the music.
Consider
\relative c' {
\repeat unfold 2 {
c d e f g
}
}
as opposed to
\repeat unfold 2 {
\relative c' {
c d e f g
}
}
The notes will be different in these two cases.
I think the simplest solution is to explicitly declare the Voice:
\context Voice {
\repeat unfold 2 {
\relative c' {
c2 d
}
}
}
works just fine. And this is a *consistent* solution. Any time unexpected
staffs show up, the solution is to explicitly declare a Voice or a Staff.
SO I'd prefer to just teach the simple solution, and I'd probably move it to
the Troubleshooting section. I don't think it's worth a section in repeats,
when the problem occurs in other places as well.
Perhaps we need a (sub)section in Notation on implicit Staff and Voice
creation that explains the LilyPond constructs that cause implicit Staff
creation so that users can know what to look for.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Doc: Clarify \relative inside \repeat issue.
On Thu, Apr 29, 2010 at 2:24 PM, Carl Sorensen wrote:
>
> If you want to use the minumum number of { and indentation levels, you can
> write
>
> \context Voice \repeat unfold 2 \relative c' { c2 d }
>
> or
>
> \context Voice \repeat unfold 2 \relative c' {
> c2 d
> }
>
> but back when the GDP was established the LilyPond format rules said we
> needed to use { } even if it wasn't required. I couldn't find this rule in
> section 3.4.3 of Contributing, so maybe it's gone away.
No, that's still around. James, could you add this rule to the CG?
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Reorganize music functions material. (issue970044)
I like the new suggestions. Just a couple of comments.
http://codereview.appspot.com/970044/diff/1/2
File Documentation/extending/programming-interface.itely (left):
http://codereview.appspot.com/970044/diff/1/2#oldcode38
Documentation/extending/programming-interface.itely:38: * Music function
syntax::
On 2010/04/29 07:13:18, Mark Polesky wrote:
Okay. That makes me want to put "Simple substitution
functions" back, but if I do that, is it better to copy the
analagous node verbatim from the NR or to have the whole
node be a stub linking to the NR?
I think a stub linking to the NR is correct. Something like
Simple substitution functions are music functions whose output music
expression is written in LilyPond format and contains function arguments
in the output expression. They are described in @ruser{Simple
substitution functions}.
http://codereview.appspot.com/970044/diff/1/3
File Documentation/notation/changing-defaults.itely (right):
http://codereview.appspot.com/970044/diff/1/3#newcode3641
Documentation/notation/changing-defaults.itely:3641: @ref{Music function
type predicates}.
On 2010/04/29 07:13:18, Mark Polesky wrote:
On 2010/04/28 21:42:05, Neil Puttock wrote:
> There's a danger here that users might think these are
> the only type predicates allowed.
>
> The list's only complete in so far as type-p-name-alist
> documents predicates used internally for music functions
> and properties.
There aren't that many other predicates out there (see
http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00713.html).
And I'm happy to add the remaining ones to the alist if
that will justify using the word "complete". (:
You also proposed a clever way to prevent labeling failed
type checks as "unknown" in the error message, which I'll
definitely add to the next patch set
(http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00725.html).
I'd like to do both.
Users can also write their own type predicates if they want to. So
perhaps we should mention "predefined type predicates"
http://codereview.appspot.com/970044/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On 4/29/10 7:12 AM, "Werner LEMBERG" wrote: > > >>> > > I like this Why instead of ? > >> c\chord #'(1 3 5 7 11) > > I like this too. I think I really like this. It allows a transparent definition of what is meant by a chord that is really easy to override. But we'll need to be sure it handles things like c\chord #'(1 3- 5-) And inversions could be handled, too. c\chord #'(3 5 1) or c\chord #'(5 1 3) We could even do bass notes c\chord #'(4 1 3 5) Chord structures could then be referenced easily (e.g. for adding to exceptions) with the scheme list #'(4 1 3- 5-) instead of with notes, which can cause some confusion. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
>> >> I like this > > Why instead of ? Honestly, I'm just looking at the syntax form, not how to use it. It simply looks good to me from a syntactical point of view. Whether it's praktical or not, I don't know. I've never used chord mode. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
Werner LEMBERG writes:
>> >
>
> I like this
>
>> c\chord #'(1 3 5 7 11)
>
> I like this too.
It is not clear to me how this would extend to
\chordmode {
c1:7+ c:5+.3- c:3-.5-.7-
}
\chordmode {
c1:sus c:sus2 c:sus4 c:5.4^3
}
\chordmode {
c1 c/g c/+g
}
c:dim7^5
and similar. It's nice, but a single mode where the full power of
voicing _and_ chords is available similarly convenient would be
preferable to me. Making chordmode and musicmode less compatible by
extending them in disparate ways is just not good strategy.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
Carl Sorensen writes: > On 4/29/10 7:12 AM, "Werner LEMBERG" wrote: > >> >> >> >> I like this > > Why instead of ? Because requires less brain than what it would need to be. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Parser docfix for tokenization of music function signatures.
--- lily/parser.yy |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lily/parser.yy b/lily/parser.yy index 99e15a4..ac0d357 100644 --- a/lily/parser.yy +++ b/lily/parser.yy @@ -1077,7 +1077,7 @@ function_scm_argument: ; /* An argument list. If a function \foo expects scm scm music, then the lexer expands \foo into the token sequence: - MUSIC_FUNCTION EXPECT_MUSIC EXPECT_SCM EXPECT_SCM + MUSIC_FUNCTION EXPECT_MUSIC EXPECT_SCM EXPECT_SCM EXPECT_NO_MORE_ARGS and this rule returns the reversed list of arguments. */ function_arglist_music_last: -- 1.6.5.3.153.g0670 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
No key signature in transposed music...
Dear list, does lilypond have something "No tonality at all" switch which ensures no key signature at all is printed in a situation like this: << \crazyatonalmusic \tranpose c fis \crazyatonalmusic ??? I am getting 6 flats for this, which is not useful since crazyatonalmusic wants to be read with dodecaphonic accidental style anyways... Thanks for any hint! Yours, Arno -- Arno Waschk a...@arnowaschk.de +491723149605 +436508950949 -- Eggert Bordellballade Berlin Neukölln 15./16./24./25. April -- Schlingensief Via Intioll.Bruxelles, Hamburg, München Mai/Juni -- Schlingensief S.M.A.S.H. Mühlheim, Berlin August/Oktober -- Feldman Patterns chrom. F Berlin -- Maxwell Davies, Sciarrino Berlin Staatsoper Oktober ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On 4/29/10 9:29 AM, "David Kastrup" wrote:
> Werner LEMBERG writes:
>
>>
>> I like this
>>
>>> c\chord #'(1 3 5 7 11)
>>
>> I like this too.
>
> It is not clear to me how this would extend to
>
> \chordmode {
>c1:7+ c:5+.3- c:3-.5-.7-
> }
\relative c' {
c1\chord #'(1 3 5 7+)
c\chord #'(1 3- 5+)
c\chord #'(1 3- 5- 7-)
}
>
> \chordmode {
>c1:sus c:sus2 c:sus4 c:5.4^3
> }
\relative c' {
c1\chord #'(1 4 5)
c\chord #'(1 2 5)
c\chord #'(1 4 5)
c\chord #'(1 4 5)
}
Or, when we define \sus4 to be equivalent to \chord #'(1 4 5), etc.,
\relative c' {
c1\sus4
c1\sus2
c1\sus4
c1\sus4
}
>
> \chordmode {
>c1 c/g c/+g
> }
\relative c' {
c1\chord
c1\chord #'(5 1 3)
c1\chord #'(5 1 3 5)
}
Or one could define \sixFour or \inversionTwo to be \chord #'(3 5 1)
I don't know what shortcut one could do for an added bass, because they can
be any pitch.
>
> c:dim7^5
c\chord #'(1 3 7--)
which could be defined as
c\dimSevenNoFive
>
> and similar. It's nice, but a single mode where the full power of
> voicing _and_ chords is available similarly convenient would be
> preferable to me. Making chordmode and musicmode less compatible by
> extending them in disparate ways is just not good strategy.
>
I understood this proposal as one that would involve eliminating \chordmode,
and replacing it with \chord #'() as part of a regular music stream. That's
what I was responding to. If we're talking about keeping chordmode, with
another syntax for note mode, I wouldn't be in favor of that.
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: No key signature in transposed music...
2010/4/29 Arno Waschk :
> Dear list,
>
> does lilypond have something "No tonality at all" switch which
> ensures no key signature at all is printed in a situation like this:
>
>
> <<
> \crazyatonalmusic
> \tranpose c fis \crazyatonalmusic
> >>
Hi,
Did you specify explicitly a key signature in "crazyatonalmusic"?
If not,
<<
\new Staff {
\key c \major
\new Voice {
\tranpose c fis
\crazyatonalmusic
}
}
>>
should do the trick (actually I think the \key c \major is even not
required, just make sure not to specify "\key c \major" explicitly in
"crazyatonalmusic").
> I am getting 6 flats for this, which is not useful since
> crazyatonalmusic wants to be read with dodecaphonic accidental style
> anyways...
For the dodecaphonic accidental style you may know you have to use
#(set-accidental-style 'dodecaphonic)
Cheers,
Xavier
--
Xavier Scheuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On 4/29/10 10:17 AM, "Carl Sorensen" wrote:
>
>
>
>
> On 4/29/10 9:29 AM, "David Kastrup" wrote:
>
>> Werner LEMBERG writes:
>>
>
>>>
>>> I like this
>>>
c\chord #'(1 3 5 7 11)
>>>
>>> I like this too.
>
> Or, when we define \sus4 to be equivalent to \chord #'(1 4 5), etc.,
>
> \relative c' {
> c1\sus4
> c1\sus2
> c1\sus4
> c1\sus4
> }
>
Oops, we'd probably have to define it as
c1\susFour
and
c1\susTwo
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Eliminate PDF deletion in Windows
On Wed, Apr 28, 2010 at 2:48 PM, Carl Sorensen wrote: > Have you tested your patch with other PDF viewers to verify that the > behavior is not worse with them? I've tested with Foxit Reader and Adobe Reader. The behavior with Foxit is improved; Lilypond can overwrite the PDF, though Foxit does not automatically detect and reload. With Adobe Reader, Lilypond cannot overwrite the file while it is open. If there are any other viewers people are commonly using in Windows, I'd be happy to check a couple. According to rumor, some of these viewers are also capable of receiving DDE messages to instruct them to e.g. reload the PDF. But even if this is the case, I wouldn't argue that Lilypond should concern itself with such - it's more a job for an IDE (some of the TeX-oriented ones, such as TeXnicCenter and WinEdt, already do support this). Thanks, Nathan Reed ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
markup-command and markup-command-list signatures
Hi,
I am currently reworking the markup command parsing. We have something
like
The available combinations of arguments (after the standard @var{layout}
and @var{props} arguments) to a markup command defined with
@code{define-markup-command} are limited as follows.
@table @asis
@item (no argument)
@itemx @var{markup-list}
@itemx @var{markup}
@itemx @var{markup markup}
@itemx @var{scheme}
@itemx @var{scheme markup}
@itemx @var{scheme scheme}
@itemx @var{scheme scheme markup}
@itemx @var{scheme scheme markup markup}
@itemx @var{scheme markup markup}
@itemx @var{scheme scheme scheme}
@end table
in the docs for markup command definitions, and nothing at all in the
docs for markup command list definitions as far as I can see.
What type signatures would be actually permissable under the assumption
that they are supported by lexer and parser?
It is somewhat clear to me that we can't have markup-list followed by
markup in the arguments. Anything else?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup-command and markup-command-list signatures
Le 29 avr. 2010 à 20:27, David Kastrup a écrit : > What type signatures would be actually permissable under the assumption > that they are supported by lexer and parser? > > It is somewhat clear to me that we can't have markup-list followed by > markup in the arguments. Anything else? I'd say, a markup-list command signature should follow the pattern: scheme* markup* markup-list* that is, any number of scheme arguments, then any number of single markup arguments, then any number of markup-list arguments, even though I don't know if having several markup list arguments is useful or not (and if it's doable). ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
Graham: ... > OTOH, what about doing something like this: > c\maj > c\dim > c\chord #'(1 4 5) > c\chord #'(1 3 5 7 11) I like this. Regards, /Karl Hammar ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
Am Donnerstag, 29. April 2010 22:20:27 schrieb Karl Hammar: > Graham: > ... > > > OTOH, what about doing something like this: > > c\maj > > c\dim We already have \dim for text diminuendo... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On Thu, Apr 29, 2010 at 03:11:13PM +0200, Valentin Villenave wrote:
> Speaking of which, I often wished we had a cool shortcut for writing
> repeats using a postfix syntax, e.g.
> { large music expression here };4
> instead of
> \repeat unfold 4 { large music expression }
That would already be handled by
{ ...} * 4
which is much more intuitive than ;4
> Yes I know: a) that's off-topic b) this will wait until GLISS starts.
Yes. If you (anybody) want GLISS to start sooner, dealing with
information only in the regtests would be a good start, since it
consists of a whole bunch of individual items/files. Very easy
for lots of people to work on it in parallel.
> -- As should this whole discussion IMO: may I take this as an
> opportunity to remind you guys that there's a whole new ML for stuff
> like that? http://lists.lilynet.net/syntax/
No. If GLISS hasn't started yet, then there's no point sending
emails to that list.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On Thu, Apr 29, 2010 at 08:55:13AM -0600, Carl Sorensen wrote: > But we'll need to be sure it handles things like > > c\chord #'(1 3- 5-) Hmm. Might we need c\chord #'(1 3++ 7--) ? I'm not prepared to claim that there's no theory of chords that includes doubly-augmented intervals relative to the base note. > We could even do bass notes > > c\chord #'(4 1 3 5) I'm not entirely comfortable about have 4 1. OTOH, I'm not overly eager to have things like c\chord #'(-4 1 3- 5-) An alternate that makes sense to me would be c\chord #'(-4 1 3es 5es) but then we're dragging language-specific definitions into this construct, which would be bad. or we could just tell people that if they mess around with custom chords (instead of using predefined \maj or \majInversionFirst ), they need to know the difference between a - sign before and after a number. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On Thu, Apr 29, 2010 at 10:17:51AM -0600, Carl Sorensen wrote: > > On 4/29/10 9:29 AM, "David Kastrup" wrote: > > > It's nice, but a single mode where the full power of > > voicing _and_ chords is available similarly convenient would be > > preferable to me. Making chordmode and musicmode less compatible by > > extending them in disparate ways is just not good strategy. > > I understood this proposal I'm not understanding any of these proposals. :) > as one that would involve eliminating \chordmode, > and replacing it with \chord #'() as part of a regular music stream. That's > what I was responding to. If we're talking about keeping chordmode, with > another syntax for note mode, I wouldn't be in favor of that. If anything happens before GLISS -- and I'm not claiming that it will -- then we *will* have a duplicate syntax for chords. We're not making a major change like removing \chordmode until after GLISS. I'm willing to consider adding new commands (like \chord), as long as it's understood that they might _also_ change after GLISS (so the command might only exist for 6-18 months in total). Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On 4/29/10 2:42 PM, "Graham Percival" wrote: > On Thu, Apr 29, 2010 at 08:55:13AM -0600, Carl Sorensen wrote: >> But we'll need to be sure it handles things like >> >> c\chord #'(1 3- 5-) > > Hmm. Might we need > c\chord #'(1 3++ 7--) > ? I'm not prepared to claim that there's no theory of chords that > includes doubly-augmented intervals relative to the base note. There is at least one common chord that uses doubly altered steps: the dim7 chord, which uses a double-flatted 7th., along with a minor thrd and a diminished fifth. So yes, we do need to allow at least --. I don't think we need to go more than two deep on the modifiers, do we? > >> We could even do bass notes >> >> c\chord #'(4 1 3 5) > > I'm not entirely comfortable about have 4 1. I'm totally comfortable with #'(4 1 3 5). I can easily parse that so that steps that come before 1 in the list are an octave down from the current pitch. > OTOH, I'm not overly > eager to have things like > c\chord #'(-4 1 3- 5-) > > An alternate that makes sense to me would be > c\chord #'(-4 1 3es 5es) > but then we're dragging language-specific definitions into this > construct, which would be bad. I think -4 is confusing, because it sounds like it is 4 steps *below* the root, instead of step 4 an octave lower. I'd prefer, if we need to do something, to do #'(4, 1 3 5), i.e. use the octave indicators we already have. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On 29 April 2010 21:36, Graham Percival wrote:
> On Thu, Apr 29, 2010 at 03:11:13PM +0200, Valentin Villenave wrote:
>> Speaking of which, I often wished we had a cool shortcut for writing
>> repeats using a postfix syntax, e.g.
>> { large music expression here };4
>> instead of
>> \repeat unfold 4 { large music expression }
>
> That would already be handled by
> { ...} * 4
> which is much more intuitive than ;4
You took the words straight out of my mouth. :)
I'm afraid I couldn't resist testing this, so if you're interested,
try the attached patch.
Cheers,
Neil
From 9c143dbdc40ec9a60ad110d2869ce7ad1ed6ca29 Mon Sep 17 00:00:00 2001
From: Neil Puttock
Date: Thu, 29 Apr 2010 21:52:12 +0100
Subject: [PATCH] Cool repeat shorthand for Valentin :)
---
lily/parser.yy |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lily/parser.yy b/lily/parser.yy
index ac0d357..3b4295d 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -994,6 +994,11 @@ repeated_music:
{
$$ = MAKE_SYNTAX ("repeat", @$, $2, $3, $4, $5);
}
+ |
+ sequential_music '*' unsigned_number
+ {
+ $$ = MAKE_SYNTAX ("repeat", @$, ly_string2scm ("unfold"), $3, $1, SCM_EOL);
+ }
;
sequential_music:
--
1.7.0.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On 4/29/10 2:48 PM, "Graham Percival" wrote: > On Thu, Apr 29, 2010 at 10:17:51AM -0600, Carl Sorensen wrote: >> >> On 4/29/10 9:29 AM, "David Kastrup" wrote: >> >>> It's nice, but a single mode where the full power of >>> voicing _and_ chords is available similarly convenient would be >>> preferable to me. Making chordmode and musicmode less compatible by >>> extending them in disparate ways is just not good strategy. >> >> I understood this proposal > > I'm not understanding any of these proposals. :) > >> as one that would involve eliminating \chordmode, >> and replacing it with \chord #'() as part of a regular music stream. That's >> what I was responding to. If we're talking about keeping chordmode, with >> another syntax for note mode, I wouldn't be in favor of that. > > If anything happens before GLISS -- and I'm not claiming that it > will -- then we *will* have a duplicate syntax for chords. > > We're not making a major change like removing \chordmode until > after GLISS. I'm willing to consider adding new commands (like > \chord), as long as it's understood that they might _also_ change > after GLISS (so the command might only exist for 6-18 months in > total). OK. I guess I was looking at this as a step to eliminating the *need* for chordmode and deprecating it (as was suggested by David originally). Of course chordmode won't be eliminated until 3.0 (because we're in a syntax freeze), but I think that if we want to eliminate anything in 3.0, we'd better have some good experience with alternatives, either in 2.13.x or 2.15.x. I was *not* envisioning these changes as a change to chordmode syntax. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On Thu, Apr 29, 2010 at 02:51:59PM -0600, Carl Sorensen wrote: > On 4/29/10 2:42 PM, "Graham Percival" wrote: > > >> c\chord #'(4 1 3 5) > > > > I'm not entirely comfortable about have 4 1. > > I'm totally comfortable with #'(4 1 3 5). I can easily parse that so that > steps that come before 1 in the list are an octave down from the current > pitch. Huh. I thought 4 1 3 5 was supposed to be a first-inversion chord, but instead you were thinking of F C E G ? on first glance, that seems like an odd chord, but as a string player I get nervous when there's only two notes at once, let alone four. How would you indicate a highly-separated chord? Such as (absolute mode) d f' d'' a''' > I'd prefer, if we need to do something, to do > > #'(4, 1 3 5), i.e. use the octave indicators we already have. Hmm. I don't know... mixing apostrophies and commas with numbers seems odd. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
Carl Sorensen writes: > On 4/29/10 2:42 PM, "Graham Percival" wrote: > >> On Thu, Apr 29, 2010 at 08:55:13AM -0600, Carl Sorensen wrote: >>> But we'll need to be sure it handles things like >>> >>> c\chord #'(1 3- 5-) >> >> Hmm. Might we need >> c\chord #'(1 3++ 7--) >> ? I'm not prepared to claim that there's no theory of chords that >> includes doubly-augmented intervals relative to the base note. > > There is at least one common chord that uses doubly altered steps: the > dim7 chord, which uses a double-flatted 7th., along with a minor thrd > and a diminished fifth. So yes, we do need to allow at least --. I > don't think we need to go more than two deep on the modifiers, do we? dim7 is double flatted with regard to the major scale, not with regard to the normal chord 7 (which is flat already). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On Thu, Apr 29, 2010 at 03:02:08PM -0600, Carl Sorensen wrote: > > OK. I guess I was looking at this as a step to eliminating the *need* for > chordmode and deprecating it (as was suggested by David originally). Of > course chordmode won't be eliminated until 3.0 (because we're in a syntax > freeze), but I think that if we want to eliminate anything in 3.0, we'd > better have some good experience with alternatives, either in 2.13.x or > 2.15.x. Yeah, but we won't *know* if we're going to eliminate anything in 3.0 until we've had GLISS. The plan was already to finish GLISS, then release 2.16.0, then spend two weeks (or whatever) merging all the syntax changes, then release 3.0.0. It would be more work to add new syntax to 2.16.0 and save all the removals for 3.0.0, but if there's a serious desire[1] for this, I'm happy to support it. [1] NB: as always, I use a strict definition of "desire", as in "the amount of effort that somebody is willing to use". Saying stuff like "I really wish that we could end world hunger, but I'm not going to volunteer or donate anything" seems like complete bunk to me. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On Thu, Apr 29, 2010 at 11:14:43PM +0200, David Kastrup wrote: > Carl Sorensen writes: > > > There is at least one common chord that uses doubly altered steps: the > > dim7 chord, which uses a double-flatted 7th., along with a minor thrd > > and a diminished fifth. So yes, we do need to allow at least --. I > > don't think we need to go more than two deep on the modifiers, do we? > > dim7 is double flatted with regard to the major scale, not with regard > to the normal chord 7 (which is flat already). It's not obvious to me whether c\chord #'(1 7) should produce "c b" or "c bes". Musically speaking, I'd look at the key signature; if it were c major, I would assume it meant "c b" since "b" is the seventh note of the scale. This may be a problem for the numeric syntax. I suppose we could define each number as being a perfect, major, or minor interval; users can adjust those intervals with + or - as required. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
Hi all, > It's not obvious to me whether > c\chord #'(1 7) > should produce "c b" or "c bes". Musically speaking, I'd look at > the key signature; if it were c major, I would assume it meant > "c b" since "b" is the seventh note of the scale. > > This may be a problem for the numeric syntax. I suppose we could > define each number as being a perfect, major, or minor interval; > users can adjust those intervals with + or - as required. Or... we could use dodecaphonic intervals, i.e. c\chord #'(1 11) is a minor seventh c\chord #'(1 12) is a major seventh Of course, none of these ideas support systems with other-than-12-tones-per-octave… =( Cheers, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On Thu, Apr 29, 2010 at 05:27:36PM -0400, Kieren MacMillan wrote: > Hi all, > > > It's not obvious to me whether > > c\chord #'(1 7) > > should produce "c b" or "c bes". Musically speaking, I'd look at > > Or... we could use dodecaphonic intervals, i.e. > > c\chord #'(1 11) is a minor seventh > c\chord #'(1 12) is a major seventh > > Of course, none of these ideas support systems with > other-than-12-tones-per-octave… =( Curse you! I got really excited when I read the first line, since it seemed like a perfect solution. Then you go and wreck everything. You broke my heart. *sniff* *sniff*I'm going to go listen to country music now. Screw you classical people with your math. (or "maths" as they say here) Cheers, - Graham "my cat left me for a guy with a bigger hard drive" PS: we could use a property to indicate the divisions of the octave. Also, most of lilypond already assumes 12 notes per octave, so this wouldn't be a huge (additional) limitation. OTOH, most people writing chords just think/say "add a 7th", not "add an 11th". Or rather, when they say "add an 11th", they're not talking about semitones. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On 4/29/10 3:12 PM, "Graham Percival" wrote: > On Thu, Apr 29, 2010 at 02:51:59PM -0600, Carl Sorensen wrote: >> On 4/29/10 2:42 PM, "Graham Percival" wrote: >> c\chord #'(4 1 3 5) >>> >>> I'm not entirely comfortable about have 4 1. >> >> I'm totally comfortable with #'(4 1 3 5). I can easily parse that so that >> steps that come before 1 in the list are an octave down from the current >> pitch. > > Huh. I thought 4 1 3 5 was supposed to be a first-inversion > chord, but instead you were thinking of > F C E G > ? on first glance, that seems like an odd chord, but as a string > player I get nervous when there's only two notes at once, let > alone four. C/F, i.e. a C major chord with an F added in the bass. > > How would you indicate a highly-separated chord? Such as > (absolute mode) > > d f' d'' a''' in relative mode, or d\chord #(1 10 15 19) > >> I'd prefer, if we need to do something, to do >> >> #'(4, 1 3 5), i.e. use the octave indicators we already have. > > Hmm. I don't know... mixing apostrophies and commas with numbers > seems odd. Well, my preference was to not do anything. I don't think that apostrophes are needed, because we can make steps be 8, 15, etc. I suppose we could make an F in the bass (of a C chord) be notated as -4, and the next octave below as -11, but that requires the user to think beyond the scale degree. I much prefer 4, (for the fourth scale degree down one octave) and 4,, (scale degree 4 down two octaves). Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On 4/29/10 3:35 PM, "Graham Percival" wrote: > On Thu, Apr 29, 2010 at 05:27:36PM -0400, Kieren MacMillan wrote: >> > OTOH, most people writing chords just think/say "add a 7th", not > "add an 11th". Or rather, when they say "add an 11th", they're > not talking about semitones. And when they say "add a 7th", they mean "add a minor 7th". The only way to get a major 7th in a chord (as far as I know in my research) is to specify "major 7th". So a "dominant 7th" or just "7th" chord is a minor seventh. The minor major seventh chord has a major 7th, the major seventh chord has a major seventh, and the augmented major seventh has a major 7th. All the res have a minor 7th, except for the diminished seventh, which has (oddly enough) a diminished 7th, which is flattened relative to the minor 7th and double flattened relative to the major 7th. That's how chordmode works right now, IIRC. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Reorganize music functions material. (issue970044)
On 2010/04/29 07:13:18, Mark Polesky wrote: There aren't that many other predicates out there (see http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00713.html). And I'm happy to add the remaining ones to the alist if that will justify using the word "complete". (: As Carl's pointed out, it'll never be complete. You also proposed a clever way to prevent labeling failed type checks as "unknown" in the error message, which I'll definitely add to the next patch set (http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00725.html). I'd like to do both. OK, though I hope you won't add this, since it's nonsense: ;(,ly:item iterator? . "item iterator") http://codereview.appspot.com/970044/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix #943. (issue956051)
LGTM. http://codereview.appspot.com/956051/diff/1/3 File lily/slur-scoring.cc (right): http://codereview.appspot.com/956051/diff/1/3#newcode86 lily/slur-scoring.cc:86: Slur_score_state::slur_direction (Grob *me) const Do you need to pass `me' here? Isn't it the same as slur_? http://codereview.appspot.com/956051/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Parser docfix for tokenization of music function signatures.
LGTM On Thu, Apr 29, 2010 at 12:42 PM, David Kastrup wrote: > --- > lily/parser.yy | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/lily/parser.yy b/lily/parser.yy > index 99e15a4..ac0d357 100644 > --- a/lily/parser.yy > +++ b/lily/parser.yy > @@ -1077,7 +1077,7 @@ function_scm_argument: > ; > > /* An argument list. If a function \foo expects scm scm music, then the > lexer expands \foo into the token sequence: > - MUSIC_FUNCTION EXPECT_MUSIC EXPECT_SCM EXPECT_SCM > + MUSIC_FUNCTION EXPECT_MUSIC EXPECT_SCM EXPECT_SCM EXPECT_NO_MORE_ARGS > and this rule returns the reversed list of arguments. */ > > function_arglist_music_last: > -- > 1.6.5.3.153.g0670 > > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: order of engravers
Hi Graham, > And have you decided whether this should just go in the > @knownissues on that page, or should it be a separate section? I think it should be in the @knownissues. > That's just it -- there isn't anybody to guide you gently into > that good night. The only clue I know about the IR is that it's > partly generated by scheme functions in scm/documentation*. > > Mark knows more, and various people like Neil, Patrick, and Carl > seem to know everything about all parts of lilypond, so maybe they > could help... but AFAIK nobody has a good grasp of the whole > system. I'll see what I can do. To be honest, I'd really like to tackle a few other issues which are far more pressing (in my scores). Cheers, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix #943. (issue956051)
Reviewers: Neil Puttock,
http://codereview.appspot.com/956051/diff/1/3
File lily/slur-scoring.cc (right):
http://codereview.appspot.com/956051/diff/1/3#newcode86
lily/slur-scoring.cc:86: Slur_score_state::slur_direction (Grob *me)
const
On 2010/04/29 22:40:10, Neil Puttock wrote:
Do you need to pass `me' here? Isn't it the same as slur_?
Oh yes, thanks for the catch. I'll amend that and push.
Description:
Fix #943.
See: http://code.google.com/p/lilypond/issues/detail?id=943
- Currently, slur direction is calculated once and possibly modified
later. Combine these routines into a single function.
- Check for a post-line-break slur first; in this case, the direction
should come from the pre-line-break slur.
- Check for a pre-line-break slur next; if found, forward its direction
to the corresponding post-line-break slur.
- If these conditions do not hold, we have an unbroken slur, so simply
calculate its direction.
Please review this at http://codereview.appspot.com/956051/show
Affected files:
M lily/include/slur-scoring.hh
M lily/slur-scoring.cc
Index: lily/include/slur-scoring.hh
diff --git a/lily/include/slur-scoring.hh b/lily/include/slur-scoring.hh
index
aeaac19c84a2e7aaddcee76b7317946e0f4cc91f..f4dc5cdbe91b5359f99c9b11d0add37d43f6439b
100644
--- a/lily/include/slur-scoring.hh
+++ b/lily/include/slur-scoring.hh
@@ -107,7 +107,7 @@ struct Slur_score_state
Bezier get_best_curve ();
void fill (Grob *);
- void set_next_direction ();
+ Direction slur_direction (Grob *) const;
vector generate_avoid_offsets () const;
Drul_array get_bound_info () const;
Index: lily/slur-scoring.cc
diff --git a/lily/slur-scoring.cc b/lily/slur-scoring.cc
index
5182072a03f9a321413bddb8b632f324c0ed38fb..b7e183718cf9aac4ef0058f5b1e74efc75920d5e
100644
--- a/lily/slur-scoring.cc
+++ b/lily/slur-scoring.cc
@@ -78,18 +78,22 @@ Slur_score_state::~Slur_score_state ()
}
/*
- copy slur dir forwards across line break.
+ If a slur is broken across a line break, the direction
+ of the post-break slur must be the same as the pre-break
+ slur.
*/
-void
-Slur_score_state::set_next_direction ()
+Direction
+Slur_score_state::slur_direction (Grob *me) const
{
- if (extremes_[RIGHT].note_column_)
-return;
+ if (Grob *left_neighbor = slur_->broken_neighbor (LEFT))
+return get_grob_direction (left_neighbor);
- if (Grob *neighbor = slur_->broken_neighbor (RIGHT))
-{
- set_grob_direction (neighbor, dir_);
-}
+ Direction dir = get_grob_direction (me);
+
+ if (Grob *right_neighbor = slur_->broken_neighbor (RIGHT))
+set_grob_direction (right_neighbor, dir);
+
+ return dir;
}
Encompass_info
@@ -215,7 +219,7 @@ Slur_score_state::fill (Grob *me)
Real lt = me->layout ()->get_dimension (ly_symbol2scm
("line-thickness"));
thickness_ = robust_scm2double (me->get_property ("thickness"), 1.0) *
lt;
- dir_ = get_grob_direction (me);
+ dir_ = slur_direction (me);
parameters_.fill (me);
extract_grob_set (me, "note-columns", columns);
@@ -277,8 +281,6 @@ Slur_score_state::fill (Grob *me)
= (extremes_[LEFT].stem_ && Stem::get_beam (extremes_[LEFT].stem_))
|| (extremes_[RIGHT].stem_ && Stem::get_beam (extremes_[RIGHT].stem_));
- set_next_direction ();
-
if (is_broken_)
musical_dy_ = 0.0;
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Eliminate PDF deletion in Windows
On 4/27/10 10:49 PM, "Nathan Reed" wrote: > Lilypond would attempt to delete the output PDF before overwriting it in > Windows > (but no other platforms). This is unnecessary and causes problems with > certain > PDF viewers, e.g. Sumatra, where the PDF is kept open in a way that allows > overwriting but not deletion. See also the discussion on bug-lilypond[1]. I've reviewed this patch, and it looks good to me. I don't run LilyPond on Windows. Nathan has tested with multiple PDF viewers, and it seems to be better on some and no worse on any of them that have been tested. Are there any objections to having me push this patch? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
On Thu, Apr 29, 2010 at 1:53 PM, Neil Puttock wrote: > I'm afraid I couldn't resist testing this, so if you're interested, > try the attached patch. That's great! You might also want to include simultaneous music (<<...>>*4). Thanks! -Jay ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
Jay Anderson writes: > On Thu, Apr 29, 2010 at 1:53 PM, Neil Puttock wrote: >> I'm afraid I couldn't resist testing this, so if you're interested, >> try the attached patch. > > That's great! You might also want to include simultaneous music > (<<...>>*4). Thanks! Wouldn't that be a fourfold unisono? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
