Changes.tely updated - 2.19.x before Feb 4th 2014

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

[dak, 2014-02-08 12:45:33]

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#new...
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.

[pkx166h, 2014-02-08 13:17:45]

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#new...
> 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)?

[pkx166h, 2014-02-08 13:19:17]

Rewrite of \repeat alternative changes as per David K's instruction.

[dak, 2014-02-08 13:41:04]

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...
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...
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.

[pkx166h, 2014-02-08 19:38:38]

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...
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...
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.

[pkx166h, 2014-02-08 19:45:00]

Corrections from David, including some @lilypond examples for alternate repeats

[dak, 2014-02-08 20:19:59]

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.

[pkx166h, 2014-02-09 22:23:46]

Added new Tuplet placement of kneed-beams feature

[pkx166h, 2014-02-10 18:39:56]

Added 2 examples for the new Kneed-Beam w\tuplet code

[Graham Percival, 2014-02-14 08:25:43]

LGTM

[pkx166h, 2014-02-16 16:12:42]

Added note about Trevor and Devon's SATB template (3720)

[janek, 2014-02-18 16:27:25]

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...
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' }

[dak, 2014-02-18 17:06:30]

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...
> 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.

[janek, 2014-02-18 18:09:08]

2014-02-18 18:06 GMT+01:00  <dak@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/012328f4caaa192f17f99a2eab7a07...
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

[dak, 2014-02-18 18:17:49]

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.

[janek, 2014-02-18 18:29:22]

sorry, i don't understand what you mean :(

2014-02-18 19:17 GMT+01:00  <dak@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/

[dak, 2014-02-18 19:02:44]

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.

[janek, 2014-02-18 19:07:30]

2014-02-18 20:02 GMT+01:00  <dak@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