[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lilypond-auto] Issue 4163 in lilypond: Patch: Woodwind Diagrams - A
From: |
lilypond |
Subject: |
Re: [Lilypond-auto] Issue 4163 in lilypond: Patch: Woodwind Diagrams - Added recorder diagram |
Date: |
Wed, 05 Nov 2014 11:33:35 +0000 |
Updates:
Labels: -Patch-review Patch-needs_work
Comment #8 on issue 4163 by address@hidden: Patch: Woodwind Diagrams -
Added recorder diagram
https://code.google.com/p/lilypond/issues/detail?id=4163
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
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings