Re: recorder diagram and some woodwind-diagram bugs
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 bug-lilyp...@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: recorder diagram and some woodwind-diagram bugs
ok here you go On Sun, Oct 12, 2014 at 2:31 AM, James pkx1...@gmail.com 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 bug-lilyp...@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond 0001-added-recorder-diagram.patch Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
recorder diagram and some woodwind-diagram bugs
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). 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 ;;; Recorder assembly instructions (define make-hidden-key-addresses (make-key-symbols 'hidden)) (define recorder-change-points ((make-named-spreadsheet '(recorder)) '())) (define (remove-last x) (reverse (cdr (reverse x (define recorder-rh-B-key-stencil (variable-column-circle-stencil 0.55)) (define recorder-rh-L-key-stencil (variable-column-circle-stencil 0.35)) (define (generate-recorder-family-entry recorder-name) (let* ((change-points (get-named-spreadsheet-column recorder-name recorder-change-points))) `(,recorder-name . ((keys . ((hidden . ((midline . ((offset . (0.0 . 0.0)) (stencil . ,midline-stencil) (text? . #f) (complexity . basic))) (r3 . ((offset . (0.0 . 1.0)) (stencil . ,column-circle-stencil) (text? . #f) (complexity . basic))) (r4 . ((offset . (0.0 . 0.0)) (stencil . ,column-circle-stencil) (text? . #f) (complexity . basic) (central-column . ((one . ((offset . ,(assoc-get 'one CENTRAL-COLUMN-HOLE-PLACEMENTS)) (stencil . ,column-circle-stencil) (text? . #f) (complexity . trill))) (two . ((offset . ,(assoc-get 'two CENTRAL-COLUMN-HOLE-PLACEMENTS)) (stencil . ,column-circle-stencil) (text? . #f) (complexity . trill))) (three . ((offset . ,(assoc-get 'three CENTRAL-COLUMN-HOLE-PLACEMENTS)) (stencil . ,column-circle-stencil) (text? . #f) (complexity . trill))) (four . ((offset . ,(assoc-get 'four CENTRAL-COLUMN-HOLE-PLACEMENTS)) (stencil . ,column-circle-stencil) (text?