Re: recorder diagram and some woodwind-diagram bugs

[erik flister]

ok here you go

On Sun, Oct 12, 2014 at 2:31 AM, James <address@hidden> wrote:
> Erik,
>
> On 12/10/14 04:05, erik flister wrote:
>> hi there-
>> sorry for cross posting to all the lists, i'd rather not subscribe and
>> this post seems to apply to all three.
>>
>> 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).
>
> Can you make it patch format?
>
> Then I can help push this through the proper review process. Although if
> you do want to wait for people to comment (and I am not qualified to ...
> sorry) then that is fine, but it will still need to be in patch format
> in the end, it's up to you.
>
> It's more likely to get more constructive reviews if it is a proper
> patch though.
>
> regards
>
> James
>
>
>
>
>
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> bug-lilypond mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>
>

0001-added-recorder-diagram.patch
Description: Binary data