Fwd: First release of ly/tablature.ly

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Fwd: First release of ly/tablature.ly

Valentin Villenave
For archival purposes, I am forwarding to the tablatures list some
previous discussions that may have taken place privately or on the
LilyPond-user mailing list.

- Valentin

Forwarded conversation
Subject: First release of ly/tablature.ly

From: <[hidden email]>
Date: 2009/6/23
To: [hidden email]
Cc: [hidden email]

I don't know much about the issues here, but here's a review, fwiw. Of
course, you'll need to update the docs also (and a regression test or 2
would be nice).

File ly/tablature.ly (right):

Line 205: tabFullNotation = {
Why not create a new context, FullTabVoice, or something like that? Do
you expect people to use \tabFullNotation mid-piece?

Line 237: \layout {
It seems to me that we have 3 versions of tablature now: the "default"
version in engraver-init.ly, the version that appears if the user
includes "tablature.ly" and the "full" version that the user gets by
including tablature.ly and using the tabFullNotation. Is there a reason
for keeping the old versions in engraver-init.ly? Perhaps we should
scrap them altogether and require that the user include tablature.ly in
order to get tabs.


lilypond-devel mailing list
[hidden email]

From: Carl D. Sorensen <[hidden email]>
Date: 2009/6/23
To: "[hidden email]" <[hidden email]>, lilypond-devel
<[hidden email]>, Marc Hohl <[hidden email]>

Thanks, Joe.
Yep, docs and regressions are in the works.  (Although Graham says that docs
aren't the developers' responsibility).
Marc originally went for a new context.  But we don't have different Voice
or Staff contexts when we change how notes are displayed.  So I don't think
we should have different TabVoice or TabStaff contexts when we change how
TabNotes are displayed.
The current structure comes because I suggested we keep the default the
same, so that we wouldn't break all of the existing tablatures.  But Marc
wanted to have TabNumbersOnly be the default (and that's why it's
implemented that way in tablature.ly).

The tabFullNotation is probably almost the same as that in engraver-init.ly.

If we don't mind breaking previously existing scores, then we can go ahead
and change the initialization to numbers only.
Thanks again,


From: Joe Neeman <[hidden email]>
Date: 2009/6/24
To: "Carl D. Sorensen" <[hidden email]>
Cc: Marc Hohl <[hidden email]>, lilypond-devel <[hidden email]>

I don't particularly mind breaking existing scores (as long as there is
a convert-ly rule to at least warn about the problem), but I don't think
the situation in the patch is particularly friendly. We've a long
tradition of choosing sensible behaviour over backwards compatibility
and I see no reason to change it now.


From: Marc Hohl <[hidden email]>
Date: 2009/7/7
To: Joe Neeman <[hidden email]>
Cc: Lily-Devel List <[hidden email]>, "Carl D. Sorensen"
<[hidden email]>

Joe Neeman schrieb:

I am not sure whether I understand your comment correctly.
What should I change to make the patch more "friendly"?

Some users called for changing the initial behavior of tablature
because they are using a combination of normal staves and tablature,
and in this situation, only numbers are shown.

To be backwards compatible with older scores, we finally came to the conclusion
that it would be best to enable the new settings by including "tablature.ly".
On the other hand, for small snippets and stuff it is convenient to use
the \TabFullNotation, which has the advantage of displaying glissando lines
correctly and offers a double stemmed half note.

I don't know whether users have typeset much tablature scores in the past,
so I cannot decide about the right behavior concerning backwards compatibility.
Personally, I think tablature was not used very often (or at least
heavily hacked
to fulfil the needs of the users) due to the lack of important
features which we are
about to support in future versions - so establishing the
\TabFullNotation as the
(improved) standard in engraver-init.ly and getting rid of this command will not
be a serious break, as far as I can see.

From: Carl D. Sorensen <[hidden email]>
Date: 2009/7/7
To: Marc Hohl <[hidden email]>, Joe Neeman <[hidden email]>
Cc: Lily-Devel List <[hidden email]>


I think that Joe means go ahead and break old scores -- do the best thing
for going forward, so make TabNumbersOnly the default behavior (like you
wanted to), and have TabFullNotation be the override.  That is, ignore my
initial suggestion to keep TabFullNotation as the default behavior.

I believe that will make things much more simple in the code if you do that.



From: Marc Hohl <[hidden email]>
Date: 2009/7/7
To: "Carl D. Sorensen" <[hidden email]>
Cc: Joe Neeman <[hidden email]>, Lily-Devel List <[hidden email]>

[...] Carl, thanks for clarification - I misunderstood Joe's message
totally, as I can see now. Ok. How should I put these things together?

As far as I can see, I should

1) put all the functions in a file scm/tablature.scm
 (I have to add this file in ly/declarations-init.ly, right?)

2) modify ly/engraver-init.ly so that tablature without stems and stuff will be
 the default situation (where do I put the \TabFullNotation command?
 Is scm/tablature.scm the right place?)

3) move the existing predefined tunings from scm/output-lib.scm
 into tablature.scm, where I can add my new tunings as well;

4) include the function add-new-clef to scm/parser-clef.scm

5) modify ly/engraver-init.ly and scm/music-functions.scm to include
 in the 'graceSettings list (a minor correction: fret numbers for grace notes
 should be set in smaller size)

6) put everything together in a patch ;-)

Any changes/corrections/improvements are appreciated!

From: Carl D. Sorensen <[hidden email]>
Date: 2009/7/7
To: Marc Hohl <[hidden email]>
Cc: Joe Neeman <[hidden email]>, Lily-Devel List <[hidden email]>

Yes, put the functions in scm/tablature.scm.  But the file should be added
in scm/lily.scm, not ly/declarations-init.ly.  We load scm files from
scm/lily.scm, and .ly (soon to be .ily, I think) files fom
\TabFullNotation (which I think should be renamed \tabFullNotation, to be
consistent with LilyPond command names) should be defined in
ly/property-init.ly, I think.
Yes, I agree with this.
Sounds good.
Yes, sounds good
Yes, that's right.

But don't forget

7) Make regression tests that test all of your code to make sure it works

8) (Ideal, but not strictly necessary)  Write documentation that shows the
use of the new features.  The documentation doesn't have to be in formal
LilyPond style (although it would be better if it were), and it doesn't have
to be implemented in the NR (although it would be better if it were), but it
should show the functionality so a documentation editor can add it to the
official LilyPond documentation.

From: Marc Hohl <[hidden email]>
Date: 2009/7/8
To: "Carl D. Sorensen" <[hidden email]>
Cc: Joe Neeman <[hidden email]>, Lily-Devel List <[hidden email]>

Carl D. Sorensen schrieb:
> [...]

Should the definitions for fret-number-tablature-format
and fret-number-tablature-format-banjobe moved to
tablature.scm too?
I don't want to alter too much of the existing structure, but it
seems somewhat consistent to me.

From: Marc Hohl <[hidden email]>
Date: 2009/7/8
To: "Carl D. Sorensen" <[hidden email]>
Cc: Joe Neeman <[hidden email]>, Lily-Devel List <[hidden email]>

Carl D. Sorensen schrieb:
Some proplems arise here due to the order in which the files are
read. I put the \overrides in ly\engraver-init.ly, but all the
callbacks declared in scm/tablature.scm don't seem to be known
at this stage, so I got myriads of error messages.

Is scm/lily.scm read before ly/engraver-init.ly?

From: Marc Hohl <[hidden email]>
Date: 2009/7/8
To: "Carl D. Sorensen" <[hidden email]>
Cc: Joe Neeman <[hidden email]>, Lily-Devel List <[hidden email]>

Marc Hohl schrieb:
Arrg! Please ignore this message - I forgot to define some
callbacks as public.

Sorry for the noise.