Axis_group_engraver + Scheme engraver for staff combining

Axis_group_engraver + Scheme engraver for staff combining

It provides an intuitive user interface
to control whether shared or separate
staves are printed, and should work
for combinations of 4 or more parts.

Currently, Axis_group_engraver reads
keepAliveInterfaces into an internal
variable during process-music, then
uses the stored value during
acknowledge-grob.

In this patched it waits to read
keepAliveInterfaces during
acknowledge-grob.

[lilypond-pkx, 2019-03-13 16:31:39]

Passes make, make check and a full make doc.

[thomasmorley651, 2019-03-13 21:22:59]

Can't review C++-code.
Some concerns in the ly-file:

https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly
File ly/divisi_engraver.ly (right):

https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly...
ly/divisi_engraver.ly:3: % From define-context-properties.scm
Here two new context-properties are defined: sharingParts and combineWithNext
This shouldn't be done in a ly-file, but in define-context-properties.scm

https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly...
ly/divisi_engraver.ly:26: except the last element of each sublist."
I don't understand the description.
The commented example below (which should likely be part of the doc-string) uses
cdr. But cdr is not a perdicate.
Am I missing something?
Anyway, such a thing should probably inserted in lily-library.scm

https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly...
ly/divisi_engraver.ly:39: (and (every
Isn't it the same as 
(lset<= equal? y x)
?
The whole thingy is used once (in the engraver definition below)
I'd delete 'proper-subset?' and do (lset<= equal? y x) there.

https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly...
ly/divisi_engraver.ly:45: 
Here I stopped for now.
Waiting for the next iteration of this patch. ;)

[saul.james.tobin, 2019-03-17 01:45:49]

Thanks, Thomas.

As you can probably tell, the Scheme code as currently submitted is more
like a proof of concept. I will go through and properly integrate it into
the Lilypond code organization.

Re cdr is not a predicate — the list being processed here is composed of
pairs, the cdr of which is ##t or ##f.

One question — is there a preferred way to get child contexts in Scheme?
Can't seem to find such a thing in the documentation but maybe I'm missing
something.

Saul

On Wed, Mar 13, 2019, 3:22 PM <thomasmorley65@gmail.com> wrote:

> Can't review C++-code.
> Some concerns in the ly-file:
>
>
>
> https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly
> File ly/divisi_engraver.ly (right):
>
>
>
https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly...
> ly/divisi_engraver.ly:3
>
<https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly...>:
> % From define-context-properties.scm
> Here two new context-properties are defined: sharingParts and
> combineWithNext
> This shouldn't be done in a ly-file, but in
> define-context-properties.scm
>
>
>
https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly...
> ly/divisi_engraver.ly:26
>
<https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly...>:
> except the last element of each sublist."
> I don't understand the description.
> The commented example below (which should likely be part of the
> doc-string) uses cdr. But cdr is not a perdicate.
> Am I missing something?
> Anyway, such a thing should probably inserted in lily-library.scm
>
>
>
https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly...
> ly/divisi_engraver.ly:39
>
<https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly...>:
> (and (every
> Isn't it the same as
> (lset<= equal? y x)
> ?
> The whole thingy is used once (in the engraver definition below)
> I'd delete 'proper-subset?' and do (lset<= equal? y x) there.
>
>
>
https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly...
> ly/divisi_engraver.ly:45
>
<https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly...>
> :
> Here I stopped for now.
> Waiting for the next iteration of this patch. ;)
>
> https://codereview.appspot.com/576540043/
>

[thomasmorley651, 2019-03-18 21:49:27]

On 2019/03/17 01:45:49, saul.james.tobin wrote:

> Re cdr is not a predicate — the list being processed here is composed of
> pairs, the cdr of which is ##t or ##f.

The description is still confusing. Do you mean something like below?

#(define (divide-true-cdr ls)
"Split @var{ls} into those elements which do and don't have a tail of value 
@code{#t}"
 (call-with-values
   (lambda () (partition (lambda (x) (eq? #t (cdr x))) ls))
   (lambda (a b) (list a b))))

#(display (divide-true-cdr '((1 . #f) (2 . #t) (3 . #f))))

=> (((2 . #t)) ((1 . #f) (3 . #f)))

> 
> One question — is there a preferred way to get child contexts in Scheme?
> Can't seem to find such a thing in the documentation but maybe I'm missing
> something.

We have AnnounceNewContext which may help.
For an usage-example see:
https://lists.gnu.org/archive/html/bug-lilypond/2019-03/msg00011.html

[dak, 2019-03-18 22:26:15]

thomasmorley65@gmail.com writes:

> On 2019/03/17 01:45:49, saul.james.tobin wrote:
>
>> Re cdr is not a predicate — the list being processed here is composed
> of
>> pairs, the cdr of which is ##t or ##f.
>
> The description is still confusing. Do you mean something like below?
>
> #(define (divide-true-cdr ls)
> "Split @var{ls} into those elements which do and don't have a tail of
> value
> @code{#t}"
>  (call-with-values
>    (lambda () (partition (lambda (x) (eq? #t (cdr x))) ls))
>    (lambda (a b) (list a b))))
>
> #(display (divide-true-cdr '((1 . #f) (2 . #t) (3 . #f))))
>
> => (((2 . #t)) ((1 . #f) (3 . #f)))

The silence of the lambdas (almost):

#(define (divide-true-cdr ls)
  "Split @var{ls} into those elements which don't and do have a tail of
  value @code{#tf}"
  (call-with-values (lambda () (partition cdr ls)) list))

#(display (divide-true-cdr '((1 . #f) (2 . #t) (3 . #f))))
=> (((2 . #t)) ((1 . #f) (3 . #f)))

-- 
David Kastrup

[saul.james.tobin, 2019-03-18 22:45:23]

Will play around with AnnounceNewContext — looks like it does what I'm
looking for. Thanks!

For segmenting list by ##t/##f tail, my code needs to preserve order. The
##t/##f value represents whether the next staff down may be condensed
upward. So:

((1 . #t) (2 . #f) (3 . #t) (4 . #t)), if we imagine the numbers as staves,
means that 1+2 may be condensed together, and 3+4 may be condensed together
(the last t/f value doesn't matter), but that 2+3 must be separate.

((1 . #t) (2 . #t) (3 . #f) (4 . #t)) would allow 1+2+3 to be condensed,
with 4 separate.

Does that clarify things?

Saul

On Mon, Mar 18, 2019, 3:49 PM <thomasmorley65@gmail.com> wrote:

> On 2019/03/17 01:45:49, saul.james.tobin wrote:
>
> > Re cdr is not a predicate — the list being processed here is composed
> of
> > pairs, the cdr of which is ##t or ##f.
>
> The description is still confusing. Do you mean something like below?
>
> #(define (divide-true-cdr ls)
> "Split @var{ls} into those elements which do and don't have a tail of
> value
> @code{#t}"
>   (call-with-values
>     (lambda () (partition (lambda (x) (eq? #t (cdr x))) ls))
>     (lambda (a b) (list a b))))
>
> #(display (divide-true-cdr '((1 . #f) (2 . #t) (3 . #f))))
>
> => (((2 . #t)) ((1 . #f) (3 . #f)))
>
>
> > One question — is there a preferred way to get child contexts in
> Scheme?
> > Can't seem to find such a thing in the documentation but maybe I'm
> missing
> > something.
>
> We have AnnounceNewContext which may help.
> For an usage-example see:
> https://lists.gnu.org/archive/html/bug-lilypond/2019-03/msg00011.html
>
>
>
>
> https://codereview.appspot.com/576540043/
>

[thomasmorley651, 2019-03-18 22:55:37]

On 2019/03/18 22:26:15, dak wrote:
> mailto:thomasmorley65@gmail.com writes:
> 
> > On 2019/03/17 01:45:49, saul.james.tobin wrote:
> >
> >> Re cdr is not a predicate — the list being processed here is composed
> > of
> >> pairs, the cdr of which is ##t or ##f.
> >
> > The description is still confusing. Do you mean something like below?
> >
> > #(define (divide-true-cdr ls)
> > "Split @var{ls} into those elements which do and don't have a tail of
> > value
> > @code{#t}"
> >  (call-with-values
> >    (lambda () (partition (lambda (x) (eq? #t (cdr x))) ls))
> >    (lambda (a b) (list a b))))
> >
> > #(display (divide-true-cdr '((1 . #f) (2 . #t) (3 . #f))))
> >
> > => (((2 . #t)) ((1 . #f) (3 . #f)))
> 
> The silence of the lambdas (almost):
> 
> #(define (divide-true-cdr ls)
>   "Split @var{ls} into those elements which don't and do have a tail of
>   value @code{#tf}"
>   (call-with-values (lambda () (partition cdr ls)) list))
> 
> #(display (divide-true-cdr '((1 . #f) (2 . #t) (3 . #f))))
> => (((2 . #t)) ((1 . #f) (3 . #f)))
> 
> -- 
> David Kastrup


Aargh, replacing `(lambda (a b) (list a b))´ with `list´ is ofcourse far better.
I considered to use simple `cdr´ instead of `(lambda (x) (eq? #t (cdr x)))´,
though one would need to ensure the `cdr´ is always a boolean, otherwise our
procedures would return differently sometimes.  Saul said so, though I thought
better be paranoid than sorry ...

[dak, 2019-03-18 23:05:02]

thomasmorley65@gmail.com writes:

> On 2019/03/18 22:26:15, dak wrote:
>
>> The silence of the lambdas (almost):
>
>> #(define (divide-true-cdr ls)
>>    "Split @var{ls} into those elements which don't and do have a tail of
>>    value @code{#f}"
>>    (call-with-values (lambda () (partition cdr ls)) list))
>
>> #(display (divide-true-cdr '((1 . #f) (2 . #t) (3 . #f))))
>> => (((2 . #t)) ((1 . #f) (3 . #f)))
>
>> --
>> David Kastrup
>
>
> Aargh, replacing `(lambda (a b) (list a b))´ with `list´ is ofcourse far
> better.
> I considered to use simple `cdr´ instead of `(lambda (x) (eq? #t (cdr
> x)))´, though one would need to ensure the `cdr´ is always a boolean,
> otherwise our procedures would return differently sometimes.  Saul said
> so, though I thought better be paranoid than sorry ...

I have problems understanding how comparing with #t rather than #f is in
any sense better for a value presumed to be boolean.  Why do you think
it is a good idea to consider 3.14 (say) equivalent to #f rather than #t
?  I mean, nothing wrong with paranoia but to me this looks like bolting
the lampshade rather than some window.

> https://codereview.appspot.com/576540043/

-- 
David Kastrup