Woodwind Diagrams - Added recorder diagram

Issue 4163

Provided by Erik Flister


Added recorder diagram

issues still to be resolved and need help:-

1h (half-covered) works for eg 'flute two',
but on my recorder thumb (T) it doesn't work
it just shows fully covered.

[pkx166h, 2014-10-12 20:33:59]

Please review and give advice.

[pkx166h, 2014-10-13 06:38:27]

passes tests.  Includes a full make doc

[pkx166h, 2014-10-18 06:54:01]

Patch on countdown for October 21st

Although I am not sure if this still needs some more work based on some of the
previous emails.

[pkx166h, 2014-10-21 10:02:41]

I'm going to leave this on for another round of countdown. I know there has been
some discussion on the mails from Erik (the author of the patch) but I cannot
(or have not) seen any replies or confirmation this is good to push as it is.

@Erik, it seemed to me there were some things that were missing or still to do
with this diagram, but I don't know if they are enough to stop the patch being
pushed.

Could you let the list know what still needs to be done (if anything) just so I
can see - as patch meister - if this really needs work or just some improvements
in the future.

[pkx166h, 2014-11-02 20:58:45]

I'm not comfortable pushing this, there were some things on the original email 

http://lists.gnu.org/archive/html/bug-lilypond/2014-10/msg00024.html

(after which I offered to help move a patch through the list) that I am simply
not qualified to say if it is still OK to push or still needs some work
(considering there are probably some other issues with Woodwind Diagrams in
general that these may or may not relate too in the LilyPond Code).

From the original email by Erik:

--snip--

attached is a recorder diagram patch, would love for feedback and for
it to be incorporated.  hopefully it's ok it's not actually in patch
format, it just drops into display-woodwind-diagrams.scm (of course a
corresponding entry needs to be added to
woodwind-data-assembly-instructions in that file as well).

my biggest problems:

- 1h (half-covered) works for eg 'flute two', but on my recorder thumb
(T) it doesn't work -- it just shows fully covered.

- why are partial covers shown as shaded, then there is no distinction
w/trills (ie 1h and 1hT are identical)?

i don't know scheme, so i was mainly pattern-matching from existing
diagrams.  some issues i had while trying to figure this out:

- what is the purpose of the baked-in cc/lh/rh grouping?

- i can't find doc for draw-instructions rules -- seems to determine
whether keys are hidden unless specified -- i didn't want that
behavior, but was stuck unexpectedly getting it for a while.

- difference between identity and return-1 -- they sound identical to
me (when xy-scaling), but gave different results.

- the style used encourages a lot of duplicated code -- it needs to be
refactored so that keys are defined as simple declarative structures
(with properties like name, group, position, complexity, stencil,
textual-representation) and graphical/textual-commands derived
therefrom.

- similarly, key positions should be described in relative terms --
most stuff is absolute w/brittle hardcoding.

- explicit support for when there is no text-override (key name
instead of graphical stencil) available.  i tripped across a
previously reported bug that doesn't seem to have made it to the issue
list even though it's a crash:
(http://lists.gnu.org/archive/html/lilypond-user/2014-09/msg00405.html):

  c^
  \markup \override #'(graphical . #f) {
      \woodwind-diagram
        #'tin-whistle
        #'()
  }

C:/Program Files (x86)/LilyPond/usr/share/lilypond/current/scm/display-woodwind-
diagrams.scm:1977:20: In procedure = in expression (= 0 (assoc-get node draw-ins
tructions)):
C:/Program Files (x86)/LilyPond/usr/share/lilypond/current/scm/display-woodwind-
diagrams.scm:1977:20: Wrong type: #f

also broken for saxophone (a different error tho), but works for piccolo.
for tin-whistle, seems to be from use of CENTRAL-COLUMN-HOLE-H-LIST
instead of CENTRAL-COLUMN-HOLE-LIST.

- when using \override #'(graphical . #f) (is there a way to call this
"textual"?) with an empty keylist, should show all possible text
stencils (as it currently does for graphical).  also, how are partial
coverings/trills handled in this case?

- would be nice if i didn't have to edit display-woodwind-diagrams.scm
and instead could just \include my raw .scm file from a .ly file.

thanks!
-erik

--snip--


I am attaching the patch (and related files) to the ticket

http://code.google.com/p/lilypond/issues/detail?id=4163

 based on current master as of now, it probably at least needs adding to the
various other files like the couple of snippets that exist showing them
(trivial) but there are some other 'woodwind' files in the main code that may
also need adjusting like 'define-woodwind-diagrams.scm' for instance.

I am setting this ticket back from push to review. But if I get nothing back at
all, I will set it back to 'Needs_work'

[mike7, 2014-11-02 21:04:27]

On Nov 2, 2014, at 10:58 PM, pkx166h@gmail.com wrote:
> 
> I'm not comfortable pushing this, there were some things on the original
> email
> 
> http://lists.gnu.org/archive/html/bug-lilypond/2014-10/msg00024.html
> 
> (after which I offered to help move a patch through the list) that I am
> simply not qualified to say if it is still OK to push or still needs
> some work (considering there are probably some other issues with
> Woodwind Diagrams in general that these may or may not relate too in the
> LilyPond Code).
> 
> From the original email by Erik:


This passed under my radar - I’ll have time to review it tomorrow.

Cheers,
MS

[mike7, 2014-11-03 11:37:49]

> On Nov 2, 2014, at 10:58 PM, pkx166h@gmail.com wrote:
> 
> i don't know scheme, so i was mainly pattern-matching from existing
> diagrams.  some issues i had while trying to figure this out:
> 
> - what is the purpose of the baked-in cc/lh/rh grouping?
> 

This was a feature of the original design based on the woodwind instruments I
needed to implement at the time.
All of the woodwind instruments I have ever written for or studied have this as
a feature.

> - i can't find doc for draw-instructions rules -- seems to determine
> whether keys are hidden unless specified -- i didn't want that
> behavior, but was stuck unexpectedly getting it for a while.
> 

That’s my fault - it was a late add-on that I still need to document.  I will
propose a patch for documentation as soon as I get LilyDev running on OS X
Yosemite.
Try something to the effect of:

(draw-instructions
              . ((,group-automate-rule
                  ,(make-central-column-hole-addresses
CENTRAL-COLUMN-HOLE-LIST))))

> - difference between identity and return-1 -- they sound identical to
> me (when xy-scaling), but gave different results.
> 

Identity returns the value passed in

(identity 3)
3

return-1 returns 1

(return-1 3)
1.0

> - the style used encourages a lot of duplicated code -- it needs to be
> refactored so that keys are defined as simple declarative structures
> (with properties like name, group, position, complexity, stencil,
> textual-representation) and graphical/textual-commands derived
> therefrom.
> 

Currently, there is a declarative structure used to define all keys.  The
structure has properties like offset, stencil, text?, and complexity.
There is a lot of data, but I don’t see that much duplicated code.
Of course, I am for refactoring as much as possible - do you have a proposal for
where that’d be useful?

> - similarly, key positions should be described in relative terms --
> most stuff is absolute w/brittle hardcoding.

What would the keys be relative to?  Currently, there is the possibility to do
one absolute offset (in an offset property).  I think that the relative idea is
interesting - perhaps the possibility to create groups of keys and to offset the
groups?  Were this to be the case, it’d be important to consult with
practitioners to make sure that the groups had anatomical sense with respect to
the way the instrument is visualized in their mind’s eye.

> 
> - explicit support for when there is no text-override (key name
> instead of graphical stencil) available.  i tripped across a
> previously reported bug that doesn't seem to have made it to the issue
> list even though it's a crash:
> (http://lists.gnu.org/archive/html/lilypond-user/2014-09/msg00405.html):
> 
>  c^
>  \markup \override #'(graphical . #f) {
>      \woodwind-diagram
>        #'tin-whistle
>        #'()
>  }
> 
> C:/Program Files
> (x86)/LilyPond/usr/share/lilypond/current/scm/display-woodwind-
> diagrams.scm:1977:20: In procedure = in expression (= 0 (assoc-get node
> draw-ins
> tructions)):
> C:/Program Files
> (x86)/LilyPond/usr/share/lilypond/current/scm/display-woodwind-
> diagrams.scm:1977:20: Wrong type: #f
> 
> also broken for saxophone (a different error tho), but works for
> piccolo.
> for tin-whistle, seems to be from use of CENTRAL-COLUMN-HOLE-H-LIST
> instead of CENTRAL-COLUMN-HOLE-LIST.
> 

Can you propose a patch to fix this?
I’ll take a look to see if I can put better default behavior when values aren’t
supplied.

> - when using \override #'(graphical . #f) (is there a way to call this
> "textual"?) with an empty keylist, should show all possible text
> stencils (as it currently does for graphical).  also, how are partial
> coverings/trills handled in this case?

There is currently no support for textual partial coverings - that would
certainly be welcome.  I couldn’t find a good convention in the literature when
I wrote the code.
For the graphical . #f, that is a great idea - hadn’t thought of it before. 
I’ll also look into that as soon as I get stuff up an running on Yosemite.

> 
> - would be nice if i didn't have to edit display-woodwind-diagrams.scm
> and instead could just \include my raw .scm file from a .ly file.
> 

You can load scm modules via the load command.

#(load foo.scm)

Otherwise, woodwind-instrument-list is publicly defined and can be changed at
runtime.

Cheers,
MS