Tablature: proper support for tie/slur- and tie/glissando-constellations

Tablature: proper support for tie/slur- and tie/glissando-constellations

If a tie is followed by a slur or a glissando, the (normally invisible)
fret number has to be displayed in parentheses.

In case of a following glissando, the left starting point is corrected
so it doesn't interfere with the closing parenthesis.

To provide a proper "signal" for these situations, the
TabNoteHead #'details were expanded by 'tied-to, which is set to #t
by the tablature tie handling routine.

[Carl, 2010-09-16 10:32:52]

Looks good to me.   Just a comment on the name of the new property to be added
to details.

Thanks,

Carl

http://codereview.appspot.com/2191042/diff/1/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/2191042/diff/1/scm/define-grobs.scm#newcode1979
scm/define-grobs.scm:1979: (tied-to . #f)))
tied-from might be a better name than tied-to, since it's the property of the
left-hand note that we're adjusting, rather than the property of the right hand
note.

And maybe something like span-start or spanner-start would be even better, since
I'd guess we want the same behavior to apply for slurs, glissandos, and bends,
all of which are spanners.  And starting the spanner at the note-head means we
want to display the number.

[marc, 2010-09-16 12:15:47]

Carl.D.Sorensen@gmail.com schrieb:
> Looks good to me.   Just a comment on the name of the new property to be
> added to details.
>
> Thanks,
>
> Carl
>
>
Hello Carl,

>
> http://codereview.appspot.com/2191042/diff/1/scm/define-grobs.scm
> File scm/define-grobs.scm (right):
>
> http://codereview.appspot.com/2191042/diff/1/scm/define-grobs.scm#newcode1979 
>
> scm/define-grobs.scm:1979: (tied-to . #f)))
> tied-from might be a better name than tied-to, since it's the property
> of the left-hand note that we're adjusting, rather than the property of
> the right hand note.
Just for clarification, since I am not a native speaker:

Consider c'4 ~ c'4 ( d'2 ).
I used "tied-to", because this value is set while evaluating the tie, so 
from this
point of view, the right note (i.e. the second c') is tied to the left 
c'. This information
is then passed to the slur/glissando routine. Am I wrong here? Is 
"tied-to" misleading?
>
> And maybe something like span-start or spanner-start would be even
> better, since I'd guess we want the same behavior to apply for slurs,
> glissandos, and bends, all of which are spanners.  And starting the
> spanner at the note-head means we want to display the number.
AFAIK, the only situation in which this may occur is when a tie is 
followed by a spanner
like slur, glissando, or bend. When a tie follows another spanner, 
lilypond already works
as expected.
But I thought about alternatives like "tie-terminate" or "terminate-tie" 
or "tie-end" before,
but "tied-to" felt just right.

Marc

http://codereview.appspot.com/2191042/

[Neil Puttock, 2010-09-16 21:14:18]

Hi Marc,

In hide-tab-note-head, you end up setting properties on bounds which aren't
noteheads (i.e., for broken bounds, the ties are bound by a
NonMusicalPaperColumn); till now you've got away with it, since the properties
being set were from the grob-interface (unlike 'details).

Try running `make check' to see what I mean. ;)

Cheers,
Neil

http://codereview.appspot.com/2191042/diff/1/input/regression/tablature-tie-s...
File input/regression/tablature-tie-slur-glissando.ly (right):

http://codereview.appspot.com/2191042/diff/1/input/regression/tablature-tie-s...
input/regression/tablature-tie-slur-glissando.ly:1: \version "2.13.35"
"2.13.34"

http://codereview.appspot.com/2191042/diff/1/input/regression/tablature-tie-s...
input/regression/tablature-tie-slur-glissando.ly:3: \header{ texidoc = "If a
slur or a glissando follows a tie, the
formatting

http://codereview.appspot.com/2191042/diff/1/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/2191042/diff/1/scm/define-grobs.scm#newcode1979
scm/define-grobs.scm:1979: (tied-to . #f)))
On 2010/09/16 10:32:52, Carl wrote:
> tied-from might be a better name than tied-to, since it's the property of the
> left-hand note that we're adjusting, rather than the property of the right
hand
> note.

How about `tied-left'?  It gives an indication of the direction of the tie away
from this notehead.

http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm
File scm/tablature.scm (right):

http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode179
scm/tablature.scm:179: (define (hide-tab-note-head grob)
This is a bit of a misnomer, since it indirectly makes some heads visible later.
 It would be better if you could avoid hiding such notes rather than hiding
them, then making them visible.

http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode181
scm/tablature.scm:181: (ly:grob-set-property! grob 'whiteout #f)
can remove this

http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode182
scm/tablature.scm:182: (ly:grob-set-nested-property! grob '(details tied-to)
#t))
This doesn't belong in 'details since it's set beyond the user's control: it
only makes sense as an internal property, so should be defined separately

http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode186
scm/tablature.scm:186: (ly:grob-set-property! grob 'whiteout #t)
can remove this

http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode275
scm/tablature.scm:275: (control-points (ly:grob-property grob 'control-points)))
remove

http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode277
scm/tablature.scm:277: (if tied-to
(and tied-to
     (show-tab-note-head left-tab-note-head)

http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode282
scm/tablature.scm:282: (ly:grob-set-nested-property! grob '(bound-details left
padding) 0.75)))
this won't happen for tied notes after a break unless you explicitly set
'tied-to outside `hide-tab-note-head'

[marc, 2010-09-17 07:01:40]

n.puttock@gmail.com schrieb:
> Hi Marc,
Hello Neil,
>
> In hide-tab-note-head, you end up setting properties on bounds which
> aren't noteheads (i.e., for broken bounds, the ties are bound by a
> NonMusicalPaperColumn); till now you've got away with it, since the
> properties being set were from the grob-interface (unlike 'details).
TO be honest, I don't understand what you mean here.
>
> Try running `make check' to see what I mean. ;)
Here neither - I see I made a mistake, because `make check' fails, but 
the output doesn't help a lot.
>
> Cheers,
> Neil
>
>
>
http://codereview.appspot.com/2191042/diff/1/input/regression/tablature-tie-s...

>
> File input/regression/tablature-tie-slur-glissando.ly (right):
>
>
http://codereview.appspot.com/2191042/diff/1/input/regression/tablature-tie-s...

>
> input/regression/tablature-tie-slur-glissando.ly:1: \version "2.13.35"
> "2.13.34"
Ok, done.
>
>
http://codereview.appspot.com/2191042/diff/1/input/regression/tablature-tie-s...

>
> input/regression/tablature-tie-slur-glissando.ly:3: \header{ texidoc =
> "If a slur or a glissando follows a tie, the
> formatting
Done. Looking at various files in input/regression, I see there are 
various formatting styles.
What about adding a file called template.ly or something similar, which 
can be copied and
edited to avoid formatting issues?
>
> http://codereview.appspot.com/2191042/diff/1/scm/define-grobs.scm
> File scm/define-grobs.scm (right):
>
> http://codereview.appspot.com/2191042/diff/1/scm/define-grobs.scm#newcode1979 
>
> scm/define-grobs.scm:1979: (tied-to . #f)))
> On 2010/09/16 10:32:52, Carl wrote:
>> tied-from might be a better name than tied-to, since it's the property
> of the
>> left-hand note that we're adjusting, rather than the property of the
> right hand
>> note.
>
> How about `tied-left'?  It gives an indication of the direction of the
> tie away from this notehead.
Carl answered to me off-list, and it seems that he misunderstood my 
idea, so at the end, he was fine with
"tied-to".
>
> http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm
> File scm/tablature.scm (right):
>
> http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode179
> scm/tablature.scm:179: (define (hide-tab-note-head grob)
> This is a bit of a misnomer, since it indirectly makes some heads
> visible later.  It would be better if you could avoid hiding such notes
> rather than hiding them, then making them visible.
How can I avoid making heads invisible? The tie routine doesn't know 
whether a slur or
glissando follows or not, so I have to make it invisible "to be on the 
safe side", add a
mark to this note that it is tied to another one and read this 
information by the slur/glissando
routine.
Or is it just the name? Well, I could use a more self-explanatory name, 
but since it is just
a shortcut, I don't know whether it's worth the effort...
>
> http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode181
> scm/tablature.scm:181: (ly:grob-set-property! grob 'whiteout #f)
> can remove this
>
Done.
> http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode182
> scm/tablature.scm:182: (ly:grob-set-nested-property! grob '(details
> tied-to) #t))
> This doesn't belong in 'details since it's set beyond the user's
> control: it only makes sense as an internal property, so should be
> defined separately
Done (I hope I did it right?)
>
> http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode186
> scm/tablature.scm:186: (ly:grob-set-property! grob 'whiteout #t)
> can remove this
Done.
>
> http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode275
> scm/tablature.scm:275: (control-points (ly:grob-property grob
> 'control-points)))
> remove
Yes, of course (these annoying little errors from cut&paste...)
>
> http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode277
> scm/tablature.scm:277: (if tied-to
> (and tied-to
>      (show-tab-note-head left-tab-note-head)
Done.
>
> http://codereview.appspot.com/2191042/diff/1/scm/tablature.scm#newcode282
> scm/tablature.scm:282: (ly:grob-set-nested-property! grob
> '(bound-details left padding) 0.75)))
> this won't happen for tied notes after a break unless you explicitly set
> 'tied-to outside `hide-tab-note-head'
I don't know what you mean - I tried to break everything ;-) and it 
seems to work:

music = {
  \override Glissando #'breakable = ##t
  c'1 ~ \break c'1 ( \break d'1 )
  c'1 ~ \break c'1 \glissando \break d'1
}

\score {
  <<
    \new Staff {
      \new Voice {
        \clef "G_8"
        \music
      }
    }
    \new TabStaff {
      \new TabVoice {
        \music
      }
    }
  >>
}

Thanks,

Marc

http://codereview.appspot.com/2191042/
>

[Neil Puttock, 2010-09-18 20:21:12]

On 2010/09/17 07:01:40, marc wrote:

> TO be honest, I don't understand what you mean here.

Add

#(ly:set-option 'check-internal-types)

to your snippet below.

Two of the bounds aren't TabNoteHeads; these are the left bounds of the ties
following a break.

> > Try running `make check' to see what I mean. ;)
> Here neither - I see I made a mistake, because `make check' fails, but 
> the output doesn't help a lot.

Is this *before* or *after* you changed the version number in the regtest?

Any regtest with a version number later than the current version will break
`make check'.

> > formatting
> Done. Looking at various files in input/regression, I see there are 
> various formatting styles.
> What about adding a file called template.ly or something similar, which 
> can be copied and
> edited to avoid formatting issues?

We could add a README similar to the one in snippets/new.

Eventually we should have a style guide for .ly snippets which deals with
correct formatting.

> > This is a bit of a misnomer, since it indirectly makes some heads
> > visible later.  It would be better if you could avoid hiding such notes
> > rather than hiding them, then making them visible.
> How can I avoid making heads invisible? The tie routine doesn't know 
> whether a slur or
> glissando follows or not, so I have to make it invisible "to be on the 
> safe side", add a
> mark to this note that it is tied to another one and read this 
> information by the slur/glissando
> routine.
> Or is it just the name? Well, I could use a more self-explanatory name, 
> but since it is just
> a shortcut, I don't know whether it's worth the effort...

I think the only sane method would be to use a scheme engraver, since you could
acknowledge interesting grobs and make typesetting decisions for the TabNoteHead
based on the grobs present at a particular timestep.

> > This doesn't belong in 'details since it's set beyond the user's
> > control: it only makes sense as an internal property, so should be
> > defined separately
> Done (I hope I did it right?)

Looks OK.  Just needs a few minor changes:

-) It's not user serviceable so should go in `all-internal-grob-properties'.

-) As a flag which is usually #f, it doesn't need to be set in define-grobs.scm:
you can set the default when reading the property instead.

-) It needs adding to an interface to prevent error messages popping up.

> > this won't happen for tied notes after a break unless you explicitly set
> > 'tied-to outside `hide-tab-note-head'
> I don't know what you mean - I tried to break everything ;-) and it 
> seems to work:

The padding tweak isn't applied to the glissando in bar five since the
left-bound for the tie isn't a TabNoteHead.

Cheers,
Neil

[Graham Percival, 2010-09-18 20:25:34]

On Sat, Sep 18, 2010 at 9:21 PM,  <n.puttock@gmail.com> wrote:
> On 2010/09/17 07:01:40, marc wrote:
>
>> Done. Looking at various files in input/regression, I see there are
>> various formatting styles.
>> What about adding a file called template.ly or something similar,
>>  which
>> can be copied and
>> edited to avoid formatting issues?
>
> We could add a README similar to the one in snippets/new.
>
> Eventually we should have a style guide for .ly snippets which deals
> with correct formatting.

Planned for the tail end of GLISS.

Cheers,
- Graham

[marc, 2010-09-19 09:06:13]

n.puttock@gmail.com schrieb:
> On 2010/09/17 07:01:40, marc wrote:
>
>> TO be honest, I don't understand what you mean here.
>
> Add
>
> #(ly:set-option 'check-internal-types)
>
> to your snippet below.
>
> Two of the bounds aren't TabNoteHeads; these are the left bounds of the
> ties following a break.
>
Ah, ok, now I see. Thanks!
>> > Try running `make check' to see what I mean. ;)
>> Here neither - I see I made a mistake, because `make check' fails, but
>
>> the output doesn't help a lot.
>
> Is this *before* or *after* you changed the version number in the
> regtest?
>
> Any regtest with a version number later than the current version will
> break `make check'.
Um, I don't know, probably before. But even if I do 'make check' now, I got

/home/marc/git/lilypond/scripts/build/out/output-distance 
--create-images --output-dir /home/marc/git/lilypond/out/test-results 
input/regression/out-test-baseline input/regression/out-test/
Traceback (most recent call last):
  File "/home/marc/git/lilypond/scripts/build/out/output-distance", line 
1261, in <module>
    main()
  File "/home/marc/git/lilypond/scripts/build/out/output-distance", line 
1258, in main
    compare_trees (args[0], args[1], name, options.threshold)
  File "/home/marc/git/lilypond/scripts/build/out/output-distance", line 
969, in compare_trees
    data.compare_trees (dir1, dir2)
  File "/home/marc/git/lilypond/scripts/build/out/output-distance", line 
812, in compare_trees
    (root, dirs, files) = os.walk (dir1).next ()
StopIteration
make: *** [local-check] Fehler 1

I don't know whether this is due to my erroneous file, but it is not 
very helpful to me...

> [...]
> I think the only sane method would be to use a scheme engraver, since
> you could acknowledge interesting grobs and make typesetting decisions
> for the TabNoteHead based on the grobs present at a particular timestep.
D'oh - I failed already once trying my luck with engravers, but  I'll 
give it a try.
Could you please sketch the functionality a bit in more detail? Do I 
still need
the 'tied-to' bit, or is the engraver responsible for the full 
appearance of the
tab note head?

Thanks,
Marc

[marc, 2010-10-20 09:12:32]

Am 18.09.2010 22:21, schrieb n.puttock@gmail.com:
> [...]
> I think the only sane method would be to use a scheme engraver, since
> you could acknowledge interesting grobs and make typesetting decisions
> for the TabNoteHead based on the grobs present at a particular timestep.
Done.
>
>> > This doesn't belong in 'details since it's set beyond the user's
>> > control: it only makes sense as an internal property, so should be
>> > defined separately
>> Done (I hope I did it right?)
>
> Looks OK.  Just needs a few minor changes:
>
> -) It's not user serviceable so should go in
> `all-internal-grob-properties'.
Done.
>
> -) As a flag which is usually #f, it doesn't need to be set in
> define-grobs.scm: you can set the default when reading the property
> instead.
Done.
>
> -) It needs adding to an interface to prevent error messages popping up.
>
Done.

Regards,

Marc
>
> http://codereview.appspot.com/2191042/
>

[marc, 2010-10-27 09:00:17]

Am 20.10.2010 11:12, schrieb Marc Hohl:
> Am 18.09.2010 22:21, schrieb n.puttock@gmail.com:
>> [...]
>> I think the only sane method would be to use a scheme engraver, since
>> you could acknowledge interesting grobs and make typesetting decisions
>> for the TabNoteHead based on the grobs present at a particular timestep.
> Done.
>>
>>> > This doesn't belong in 'details since it's set beyond the user's
>>> > control: it only makes sense as an internal property, so should be
>>> > defined separately
>>> Done (I hope I did it right?)
>>
>> Looks OK.  Just needs a few minor changes:
>>
>> -) It's not user serviceable so should go in
>> `all-internal-grob-properties'.
> Done.
>>
>> -) As a flag which is usually #f, it doesn't need to be set in
>> define-grobs.scm: you can set the default when reading the property
>> instead.
> Done.
>>
>> -) It needs adding to an interface to prevent error messages popping up.
>>
> Done.
>
> Regards,
>
> Marc
Anyone?

I know, most developers are extremely busy right now.

This particular feature isn't listed on the tracker, but since 2.14 will 
provide
a major change concerning the tablature handling, I think it is 
important that
tablature should work properly out of the box.

Sorry for being too pushy, I know that there are more important things than
tablature around for now ...

Regards,

Marc

http://codereview.appspot.com/2191042/

[valentin_villenave.net, 2010-10-27 10:14:11]

On Wed, Oct 27, 2010 at 11:00 AM, Marc Hohl <marc@hohlart.de> wrote:
> I know, most developers are extremely busy right now.
>
> This particular feature isn't listed on the tracker, but since 2.14 will
> provide
> a major change concerning the tablature handling, I think it is important
> that
> tablature should work properly out of the box.

I think we wouldn't want 2.14 to be released without your patch. I
have opened a tracker page about it:
http://code.google.com/p/lilypond/issues/detail?id=1366

I haven't made this a Critical priority, but it might be appropriate
to raise the priority. I'm not sure; hopefully this will get reviewed
and approved even with the default priority.

> Sorry for being too pushy, I know that there are more important things than
> tablature around for now ...

Sometimes it's ok to be pushy -- and I'm way ahead of you in this regard :-)

Cheers,
Valentin.

[Graham Percival, 2010-10-27 11:30:59]

On Wed, Oct 27, 2010 at 11:14 AM, Valentin Villenave
<valentin@villenave.net> wrote:
> On Wed, Oct 27, 2010 at 11:00 AM, Marc Hohl <marc@hohlart.de> wrote:
>> This particular feature isn't listed on the tracker, but since 2.14 will
>
> I haven't made this a Critical priority,

It's not going to be.  You want 2.14 asap, right?  :)

>> Sorry for being too pushy, I know that there are more important things than
>> tablature around for now ...
>
> Sometimes it's ok to be pushy -- and I'm way ahead of you in this regard :-)

Unfortunately, these days you *need* to be pushy to get stuff done.  I
have some proposals to remedy this, which we'll talk about as the
first policy debate in GOP.


But until then: yes, please be pushy.  :)

Cheers,
- Graham

[marc, 2010-10-27 18:30:36]

Am 27.10.2010 12:14, schrieb Valentin Villenave:
> On Wed, Oct 27, 2010 at 11:00 AM, Marc Hohl<marc@hohlart.de>  wrote:
>    
>> I know, most developers are extremely busy right now.
>>
>> This particular feature isn't listed on the tracker, but since 2.14 will
>> provide
>> a major change concerning the tablature handling, I think it is important
>> that
>> tablature should work properly out of the box.
>>      
> I think we wouldn't want 2.14 to be released without your patch. I
> have opened a tracker page about it:
> http://code.google.com/p/lilypond/issues/detail?id=1366
>    
Thanks, Valentin!
> I haven't made this a Critical priority, but it might be appropriate
> to raise the priority. I'm not sure; hopefully this will get reviewed
> and approved even with the default priority.
>
>    
>> Sorry for being too pushy, I know that there are more important things than
>> tablature around for now ...
>>      
> Sometimes it's ok to be pushy -- and I'm way ahead of you in this regard :-)
>    
:-)

Best regards,

Marc
> Cheers,
> Valentin.
>
>    

[Carl, 2010-10-28 12:53:01]

LGTM.

However, I'm a bit nervous about putting bends as well into the
Tab_tie_follow_engraver.  Not that the engraver won't work, but that the
Tab_tie_follow_engraver won't be part of the documentation.

Currently, I view Scheme engravers as a way for users (and snippets) to add
engraver functionality, but not as an optimal way to add core functionality.

I'm not asking you to change your code, but I'm trying to send up a caution flag
to see what others might say about it.

Thanks,

Carl

http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-t...
File input/regression/tablature-tie-slur-glissando.ly (right):

http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-t...
input/regression/tablature-tie-slur-glissando.ly:1: \version "2.13.37"
2.13.38

[Trevor Daniels, 2010-10-28 18:34:41]

I've not reviewed the code but I share Carl's concern about scheme engravers if
there is no way of documenting them in the IR.  If the grobs have any
user-servicable properties they must be properly documented.

Trevor

[marc, 2010-10-28 19:48:24]

Am 28.10.2010 20:34, schrieb tdanielsmusic@googlemail.com:
> I've not reviewed the code but I share Carl's concern about scheme
> engravers if there is no way of documenting them in the IR.  If the
> grobs have any user-servicable properties they must be properly
> documented.
Ok, I see the point, but in this case, there are only internal 
properties involved.

More generally, I suspect more scheme engravers to come, so a proper way 
of getting them
well documented would be fine.

Marc
>
> Trevor
>
>
> http://codereview.appspot.com/2191042/
>

[marc, 2010-10-28 19:54:26]

Am 28.10.2010 14:53, schrieb Carl.D.Sorensen@gmail.com:
> LGTM.
>
> However, I'm a bit nervous about putting bends as well into the
> Tab_tie_follow_engraver.  Not that the engraver won't work, but that the
> Tab_tie_follow_engraver won't be part of the documentation.

I think you misunderstood the TODO. I did not want to propose the bend 
engraver to be
part of the Tab_tie_follow_engraver, but a tie followed by a bend should 
be handled
exactly as a tie/slur or a tie/glissando combination.
>
> Currently, I view Scheme engravers as a way for users (and snippets) to
> add engraver functionality, but not as an optimal way to add core
> functionality.

I understand your argument, but I think that it would be better to 
include scheme engravers
into the docs before recoding the Tab_tie_follow_engraver in c++. At 
least, I cannot cope with this.
Aside from that, I think that more extensions on the scheme side 
(including engravers)
are about to come.

Marc

>
> I'm not asking you to change your code, but I'm trying to send up a
> caution flag to see what others might say about it.
>
> Thanks,
>
> Carl
>
>
>
>
http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-t...

>
> File input/regression/tablature-tie-slur-glissando.ly (right):
>
>
http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-t...

>
> input/regression/tablature-tie-slur-glissando.ly:1: \version "2.13.37"
> 2.13.38
>
> http://codereview.appspot.com/2191042/
>

[c_sorensen, 2010-10-28 22:15:48]

On 10/28/10 1:54 PM, "Marc Hohl" <marc@hohlart.de> wrote:

> Am 28.10.2010 14:53, schrieb Carl.D.Sorensen@gmail.com:
>> Currently, I view Scheme engravers as a way for users (and snippets) to
>> add engraver functionality, but not as an optimal way to add core
>> functionality.
> 
> I understand your argument, but I think that it would be better to
> include scheme engravers
> into the docs before recoding the Tab_tie_follow_engraver in c++. At
> least, I cannot cope with this.
> Aside from that, I think that more extensions on the scheme side
> (including engravers)
> are about to come.
> 

I would *love* to have a way to document Scheme engravers such that we could
include them in the docs, but at present I have no knowledge of how to do
so.

Can anybody shed any light on this?

Thanks,

Carl

[marc, 2010-10-29 09:03:46]

Am 28.10.2010 14:53, schrieb Carl.D.Sorensen@gmail.com:
> LGTM.
>
> However, I'm a bit nervous about putting bends as well into the
> Tab_tie_follow_engraver.  Not that the engraver won't work, but that the
> Tab_tie_follow_engraver won't be part of the documentation.
>
> Currently, I view Scheme engravers as a way for users (and snippets) to
> add engraver functionality, but not as an optimal way to add core
> functionality.
>
> I'm not asking you to change your code, but I'm trying to send up a
> caution flag to see what others might say about it.
>
> Thanks,
>
> Carl
>
>
>
>
http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-t...

>
> File input/regression/tablature-tie-slur-glissando.ly (right):
>
>
http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-t...

>
> input/regression/tablature-tie-slur-glissando.ly:1: \version "2.13.37"
> 2.13.38
Done.
>
> http://codereview.appspot.com/2191042/
>

[Carl, 2010-10-31 03:33:46]

I've put a new patch up on Rietveld, with the Scheme engraver moved to a C++
engraver to avoid the challenges with documentation.

http://codereview.appspot.com/2723043

Thanks,

Carl