Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
LGTM with a suggestion
https://codereview.appspot.com/60490050/diff/90001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/60490050/diff/90001/Documentation/changes.tely#newcode122
Documentation/changes.tely:122: Scheme functions and identifiers can now
be used as output definitions.
An example would be probably nice - here's one:
coloredNotes =
#(define-scheme-function (parser location col)(color?)
#{
\layout {
\context {
\Staff
\override NoteHead #'color = #col
}
}
#})
\layout { \coloredNotes #blue }
{ c' }
https://codereview.appspot.com/60490050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
On 2014/02/18 16:27:25, janek wrote:
LGTM with a suggestion
https://codereview.appspot.com/60490050/diff/90001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/60490050/diff/90001/Documentation/changes.tely#newcode122
Documentation/changes.tely:122: Scheme functions and identifiers can
now be used
as output definitions.
An example would be probably nice - here's one:
coloredNotes =
#(define-scheme-function (parser location col)(color?)
#{
\layout {
\context {
\Staff
\override NoteHead #'color = #col
}
}
#})
\layout { \coloredNotes #blue }
{ c' }
That example is disturbing since it is not really about using a function
as an output definition, but rather about using a function as a
_context_ definition. You usually would not expect the above to work
but
\layout { indent = #0 \coloredNotes #blue }
to fail. But exactly that will happen. The actual purpose is more like
\layout {
\some-parameterized-function-from-my-standard-include-file-generating-the-whole-layout-block
#first-parameter #second-parameter #third-parameter
possibly additional tweaking
}
I think that turning \coloredNotes into a context definition producer by
just removing the \layout { and matching } without any other change
would work fine and make a nice example. Just not an example for this
particular item. And it turns out that a music function doing that
override would work equally well in this location, so even for context
definitions it might make more sense to use an example including
engravers (since you can't do _that_ with a music function).
Maybe something setting up completion engravers with some parameters?
On the other hand, you might want to do this using a context
_modification_ since that is easy to use in _different_ contexts.
It's suprisingly hard to find some really good and _necessary_ use for
all of those. Still, it's better to have them working as expected
rather than not.
https://codereview.appspot.com/60490050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
2014-02-18 18:06 GMT+01:00 d...@gnu.org:
That example is disturbing since it is not really about using a function
as an output definition, but rather about using a function as a
_context_ definition. You usually would not expect the above to work
but
\layout { indent = #0 \coloredNotes #blue }
to fail. But exactly that will happen. The actual purpose is more like
\layout {
\some-parameterized-function-from-my-standard-include-file-generating-the-whole-layout-block
#first-parameter #second-parameter #third-parameter
possibly additional tweaking
}
I'm not sure if this will help you, but i can show you something
closer to a real-life example: i needed this stuff for generating
custom contexts with a fuction.
IIRC, before your improvement (i.e. before issue 3793) i had to do it
like this:
https://github.com/openlilylib/snippets/commit/012328f4caaa192f17f99a2eab7a07b41d095878
Your change should make it possible to use define-scheme-function (and
drop the (ly:parser-define! parser '$defaultlayout #{ bit) - if i
remember correctly (haven't worked on it for some time).
See also create custom context definitions using a scheme function
thread on -user.
I think that turning \coloredNotes into a context definition producer by
just removing the \layout { and matching } without any other change
would work fine and make a nice example.
You mean something like this?
coloredNotes =
#(define-scheme-function (parser location col)(color?)
#{
\layout {
\context {
\Staff
\override NoteHead #'color = #col
}
}
#})
\coloredNotes #blue
{ c' }
This example doesn't compile for me, i get error: bad expression
type (using 82bc9ad690, pretty close to current master)
Anyway, i'm sorry but i may not have more time to discuss this right now... :-(
best,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
On 2014/02/18 18:09:08, janek wrote:
I think that turning \coloredNotes into a context definition
producer by
just removing the \layout { and matching } without any other change
would work fine and make a nice example.
You mean something like this?
coloredNotes =
#(define-scheme-function (parser location col)(color?)
#{
\layout {
\context {
\Staff
\override NoteHead #'color = #col
}
}
#})
\coloredNotes #blue
{ c' }
This example doesn't compile for me, i get error: bad expression
type (using 82bc9ad690, pretty close to current master)
It would help to read the whole description from beginning to end.
It's just one sentence, so I did not expect it to be easy to
misinterpret it by wildly applying the second half to some place where
it has nothing to do with the first part of the sentence.
coloredNotes =
#(define-scheme-function (parser location col)(color?)
#{
\context {
\Staff
\override NoteHead #'color = #col
}
#})
\layout { \coloredNotes #blue }
{ c' }
And now also
\layout { indent = 0 \coloredNotes #blue }
will work.
https://codereview.appspot.com/60490050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
sorry, i don't understand what you mean :(
2014-02-18 19:17 GMT+01:00 d...@gnu.org:
On 2014/02/18 18:09:08, janek wrote:
I think that turning \coloredNotes into a context definition
producer by
just removing the \layout { and matching } without any other change
would work fine and make a nice example.
You mean something like this?
coloredNotes =
#(define-scheme-function (parser location col)(color?)
#{
\layout {
\context {
\Staff
\override NoteHead #'color = #col
}
}
#})
\coloredNotes #blue
{ c' }
This example doesn't compile for me, i get error: bad expression
type (using 82bc9ad690, pretty close to current master)
It would help to read the whole description from beginning to end.
It's just one sentence, so I did not expect it to be easy to
misinterpret it by wildly applying the second half to some place where
it has nothing to do with the first part of the sentence.
coloredNotes =
#(define-scheme-function (parser location col)(color?)
#{
\context {
\Staff
\override NoteHead #'color = #col
}
#})
\layout { \coloredNotes #blue }
{ c' }
And now also
\layout { indent = 0 \coloredNotes #blue }
will work.
https://codereview.appspot.com/60490050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
On 2014/02/18 18:29:22, janek wrote: sorry, i don't understand what you mean :( I quoted the original description, I quoted the code you posted, I listed the code that one arrives at when actually following the description, and I gave an example of what works with that changed code. I suggest that you just forget about it until you have the leisure to read and contemplate the full comment #15 including its quoted material. I don't see that we are getting anywhere in that manner. https://codereview.appspot.com/60490050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
2014-02-18 20:02 GMT+01:00 d...@gnu.org: I suggest that you just forget about it until you have the leisure to read and contemplate the full comment #15 including its quoted material. I don't see that we are getting anywhere in that manner. yes, it seems you're right. sorry... j ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
LGTM https://codereview.appspot.com/60490050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
Reviewers: dak,
Message:
On 2014/02/08 12:45:33, dak wrote:
https://codereview.appspot.com/60490050/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/60490050/diff/1/Documentation/changes.tely#newcode108
Documentation/changes.tely:108: Chord change detection in
@code{\repeat}
alternatives now happens in
This is a special case of several properties at the start of a repeat
alternative are reset to the value at the start of the first
alternative. This
currently also affects the current meter, and the current measure
position.
We probably should also add the current key and active accidentals
here, but at
the current point of time it's the above.
Thanks, I've reworded the paragraph.
Would it be possible (useful?) to have some simple @code{} examples to
better illustrate some of the Scheme entries (rather than complete
@lilypond or @example examples)?
Description:
Changes.tely updated - 2.19.x before Feb 4th 2014
Documented all new enhancements and features since 2.19.0 was released
up until current master (Feb 4 2014).
Contains Information for the following fixed Tracker Issues
3753, 3761, 3772, 3780, 3793, 3810, 3814, 3815, 3817, 3818, 3821 and
3835
Please review this at https://codereview.appspot.com/60490050/
Affected files (+61, -0 lines):
M Documentation/changes.tely
Index: Documentation/changes.tely
diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index
19f2da0da8509151116c6848edc83f36682715c9..e6f0bcdbdaa36829d4635892352c8962b4cdd9d5
100644
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -60,6 +60,67 @@ which scares away people.
* only show user-visible changes.
@end ignore
+@item
+@code{Partcombiner}'s handing of repeated note durations has been
+improved.
+
+@item
+@code{\lyricsto} and @code{\addLyrics} have been @q{harmonized}. Both
+now accept the same kind of delimited argument list that @code{\lyrics}
+and @code{\chords} accept. Backward compatibility has been added so
+music identifiers (i.e. @code{\mus}) are permitted as arguments. A
+@code{convert-ly} rule has been added that removes redundant uses of
+@code{\lyricmode} and rearranges combinations with context starters such
+that @code{\lyricsto} in general is applied last (i.e. like
+@code{\lyricmode} would be).
+
+@item
+Scheme functions and identifiers can now be used as output definitions.
+
+@item
+Scheme expressions can now be used as chord constituents.
+
+@item
+Improved visual spacing of small and regular @q{MI} Funk and Walker
+noteheads so they are now the same width as other shaped notes in
+their respective sets. @code{SOL} noteheads are also now visually
+improved when used with both the normal Aiken and Sacred Harp heads, as
+well as with the thin variants.
+
+@item
+@code{LeftEdge} now has a definable @code{Y-extent} (i.e.vertical). See
+@rinternals{LeftEdge}.
+
+@item
+Added a new @code{make-path-stencil} function that supports all
+@code{path} commands both relative and absolute:
+
+@code{lineto}, @code{rlineto}, @code{curveto}, @code{rcurveto},
+@code{moveto}, @code{rmoveto}, @code{closepath}. The function also
+supports @q{single-letter} syntax used in standard SVG path commands:
+
+@code{L}, @code{l}, @code{C}, @code{c}, @code{M}, @code{m}, @code{Z} and
+@code{z}. The new command is also backward-compatible with the original
+@code{make-connected-path-stencil} function. Also see
+@file{scm/stencil.scm}.
+
+@item
+Chord change detection in @code{\repeat} alternatives now happens in
+relation to the chord active at the @emph{beginning} of the @emph{first}
+alternative.
+
+@item
+Improved MIDI output for breathe marks. After tied notes, breaths take
+time @emph{only} from the last note of the tie; e.g.
+@code{@{ c4~ c8 \breathe @}} performs as @code{@{ c4~ c16 r @}} instead
+of @code{@{ c4 r8 @}}. This is more consistent with articulations and
+how humans interpret breaths after ties. It now also makes it easier to
+align simultaneous breathe marks over multiple parts, all with different
+note lengths.
+
+@item
+A new note head style for Tabulature has been added;
+@code{TabNoteHead.style = #'slash}.
@item
Four new Clefs have been added. @emph{Double G}, @emph{Tenor G},
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
https://codereview.appspot.com/60490050/diff/20001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/60490050/diff/20001/Documentation/changes.tely#newcode64
Documentation/changes.tely:64: @code{Partcombiner}'s handing of repeated
note durations has been
It has not been improved but rather made to work at all. Bug fix -
we don't mention it at all in the changes.
https://codereview.appspot.com/60490050/diff/20001/Documentation/changes.tely#newcode108
Documentation/changes.tely:108: Several @q{propeties} including chord,
key and accidental changes are
properties. But this is a bit hand-wavy and confusing. Let's see:
Context properties named in the @samp{alternativeRestores} property are
restored to their value at the start of the first alternative in
subsequent alternatives.
The default set restores measure position, current chord (for the sake
of showing chord changes) and current meter.
End of proposal... key and accidentals are not yet in the current set of
restored properties. It might make sense to put them there as well.
What is somewhat tricky here is that the property restoration works via
iterators in whatever context may get to see the \repeat/\volta stuff.
So the key stuff might behave trickily. We probably still want to try
it out and see whether people complain. The safest bet is having
\repeat/\volta everywhere where you want it, and it's also safer when
using \unfoldRepeats.
https://codereview.appspot.com/60490050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
https://codereview.appspot.com/60490050/diff/20001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/60490050/diff/20001/Documentation/changes.tely#newcode64
Documentation/changes.tely:64: @code{Partcombiner}'s handing of repeated
note durations has been
On 2014/02/08 13:41:04, dak wrote:
It has not been improved but rather made to work at all. Bug fix -
we don't
mention it at all in the changes.
removed
https://codereview.appspot.com/60490050/diff/20001/Documentation/changes.tely#newcode108
Documentation/changes.tely:108: Several @q{propeties} including chord,
key and accidental changes are
On 2014/02/08 13:41:04, dak wrote:
properties. But this is a bit hand-wavy and confusing. Let's see:
Context properties named in the @samp{alternativeRestores} property
are restored
to their value at the start of the first alternative in subsequent
alternatives.
The default set restores measure position, current chord (for the sake
of
showing chord changes) and current meter.
Thanks. I'll make a new patch with some @lilypond examples as I think I
get what is being said here and have created some simple examples.
Although if you think I have missed the point, feel free to edit them.
So this sounds like (and from my cursory experiments with lilypond-book
compiling snippets) that bits of the NR
http://lilypond.org/doc/v2.19/Documentation/notation/long-repeats are no
longer needed now.
--snip--
@lilypond[fragment,quote,relative=2]
\partial 4
\repeat volta 2 { e4 | c2 e | }
\alternative {
{
f2 d |
\set Timing.measureLength = #(ly:make-moment 3/4)
g4 g g % optional bar check is allowed here
}
{
\set Timing.measureLength = #(ly:make-moment 4/4)
a2 a |
}
}
g1 |
@end lilypond
--snip--
When I compile this with and without the \set Timing command, it makes
no difference at all. So is this what is now 'changed'?
If so I'll make some edits in the NR too, while it is fresh in my head -
but in a new patch for a new tracker.
End of proposal... key and accidentals are not yet in the current set
of
restored properties. It might make sense to put them there as well.
What is
somewhat tricky here is that the property restoration works via
iterators in
whatever context may get to see the \repeat/\volta stuff.
So the key stuff might behave trickily. We probably still want to try
it out
and see whether people complain. The safest bet is having
\repeat/\volta
everywhere where you want it, and it's also safer when using
\unfoldRepeats.
https://codereview.appspot.com/60490050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x before Feb 4th 2014 (issue 60490050)
On 2014/02/08 19:38:38, J_lowe wrote:
So this sounds like (and from my cursory experiments with
lilypond-book
compiling snippets) that bits of the NR
http://lilypond.org/doc/v2.19/Documentation/notation/long-repeats are
no longer
needed now.
--snip--
@lilypond[fragment,quote,relative=2]
\partial 4
\repeat volta 2 { e4 | c2 e | }
\alternative {
{
f2 d |
\set Timing.measureLength = #(ly:make-moment 3/4)
g4 g g % optional bar check is allowed here
}
{
\set Timing.measureLength = #(ly:make-moment 4/4)
a2 a |
}
}
g1 |
@end lilypond
--snip--
When I compile this with and without the \set Timing command, it makes
no
difference at all. So is this what is now 'changed'?
Yes. Though after removing the \set commands, the comment is wrong.
If so I'll make some edits in the NR too, while it is fresh in my head
- but in
a new patch for a new tracker.
Sounds good.
https://codereview.appspot.com/60490050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
