ok here you go
On Sun, Oct 12, 2014 at 2:31 AM, James <[email protected]> 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/bug-lilypond >> >
0001-added-recorder-diagram.patch
Description: Binary data
_______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
