2015-04-16 4:55 GMT+02:00 Carl Sorensen <c_soren...@byu.edu>:
> Hi Harm,
>
> On 4/15/15 4:30 PM, "Thomas Morley" <thomasmorle...@gmail.com> wrote:
>
>>Hi Carl,
>>
>>before going into details, let us decide how to proceed.
>>
>>The current patch was intended to be not more than maintaining the
>>stuff different.
>>First step seemed to me putting the needed data into an alist.
>>
>>2015-04-13 4:22 GMT+02:00 <carl.d.soren...@gmail.com>:
>>
>>> It seems to me that this patch is mostly maintaining the mix of parsing
>>> and display; it's just putting the stuff into a list first.
>>
>>So you are absolutely right.
>>
>>I think you would prefer to dig in deeper, though.
>
> My impression (although I haven't studied it carefully as recently as you
> have, so I might be wrong) is that the current system goes through the
> chord and creates a bunch of markup information that it puts together into
> a markup.
>
> Changing it to put the markup information in an alist seems to still mix
> the markup and the parsing. The stuff that seems to me should go in the
> alist is structural information about the chord, rather than markup
> information.
You wrote about a chord-analyzer on Rietveld.
Seems I have difficulties to fully understand what you think.
The chord-info-procedure was intended to put out an analysis of the
chord representing it in an alist.
Let's have a look at an example:
\new ChordNames
\chordmode {
fis1:m5-.7+.9-.11+.13-/ces
}
chord-info would return:
(list (list 'root-info
(cons (quote note-name) "F")
(list 'alteration-info
(cons (quote alteration) 1/2)
(cons 'accidental-glyph
"accidentals.sharp")))
(cons (quote chord-prefix-spacer) 0)
(list 'prefixes
(list 'minor-chord-modifier
simple-markup
"m"))
(list 'chord-name-separator
hspace-markup
0.5)
(list 'main-info
(list 'major-seven-symbol
line-markup
(list (markup #:triangle #f))))
(list 'alterations
(list (list 'alteration-info
(cons (quote alteration) -1/2)
(cons 'accidental-glyph
"accidentals.flat"))
(cons (quote number) "5"))
(list (list 'alteration-info
(cons (quote alteration) -1/2)
(cons 'accidental-glyph
"accidentals.flat"))
(cons (quote number) "9"))
(list (list 'alteration-info
(cons (quote alteration) 1/2)
(cons 'accidental-glyph
"accidentals.sharp"))
(cons (quote number) "11"))
(list (list 'alteration-info
(cons (quote alteration) -1/2)
(cons 'accidental-glyph
"accidentals.flat"))
(cons (quote number) "13")))
(list (quote suffixes))
(list (quote addings))
(list 'bass-info
(list 'slash-chord-separator
simple-markup
"/")
(cons (quote note-name) "C")
(list 'alteration-info
(cons (quote alteration) -1/2)
(cons 'accidental-glyph
"accidentals.flat"))))
The entries for 'minor-chord-modifier, 'chord-name-separator and a few
others contain markups. If I didn't overlook something they all are
coming from the relevant context-properties.
Those could be called later when putting together the markup.
The entries for 'accidental-glyph could be found later as well.
Is that like you'd prefer?
What about the 'note-name for root and bass?
Thea are simple strings.
>
> So for me, the alist you are creating doesn't even really pave the way for
> the kind of separation I envision.
>>>
>>>
>>>https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-na
>>>mes.scm#newcode395
>>> scm/chord-ignatzek-names.scm:395: ;;;; Step 2: Define formatter for the
>>> chord-elements using this list
>>> I'm not sure how this separation between step 1 and step 2 really
>>> accomplishes the stated goal of the patch. Can you give an example of
>>> how this makes it easier to define a new display style for a chord?
>>
>>This patch doesn't pretend to provide a user-interface for it.
>
> I wasn't asking for a user interface. I was more just asking for a
> logical sketch of how it would work.
>
>
>
>>Already possible is the following, though.
>
>
> I couldn't make the following code work. I don't have chord-info, or
> format-alterations, or any of the other format-*. Are you proposing this
> as a potential way to work with the things in your patch, and that
> chord-info would result from a call to ChordNamer? Or am I totally
> missing things here?
Sorry not making myself clear enough.
I shouldn't post anything if I'm exhausted (I was already told that
I'm hard to understand then.)
That code only works with my patch applied.
>
> And I have no desire to stand in the way of your patch, if it's moving
> things forward in a way that you have found useful.
I really hope I didn't offend you in any way!
Your input is very helpful and highly apreciated!
>
> Thanks,
>
> Carl
>
Thanks,
Harm
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
