Re: Request for Comment - Chordname strategy

[Jan Nieuwenhuizen]

<address@hidden> writes:

[cc to devel list]

> I mean it's very difficult to do. As you have already noted, chord name
> preferences are very idiosyncratic. A rule-based system is definitely
> possible (as the existing code mostly demonstrates). However, a rule-based
> system that accomodates a wide range of preferences is much more difficult.

Ok.  So, as far as you are concerned, the options are: have something
very flexible that will be broken for years to come, or have something
more pragmatic that works.

>  What I really mean is that I'd like the grammar of a .ly to drive
> the output much more directly than it currently does. i.e. that the
> .ly grammar could encode markup like "separate these parts with
> '/'", superscript this part, &c.  This would, of course be layered
> on top of the current scm markup system as the existing code is.

[fyi: the scm markup as we now it now, is probably going to be replaced]

> Pros: Extreme flexibility.
>
> Cons: inability to flip between, say, banter and jazz chords systems with a
> single source code change, since much of what is currently encoded in styles
> would now be encoded in .ly source.

Ok.  That kind of switching is nice, theoretically, but rather
useless, esp. if the outcome is not very good.

> e.g.    Something along these lines. c:maj7[5+/9+] (please ignore the
> details).
>
> c:    ->  output the root name
> maj  -> output the preference symbol for maj.
> 7 -> output seven.
> ( -> output the preference code for alterations.  e.g.  ''(simple-super " or
> ' (simple super "("
> 5+ -> output the code for #5 according to current style.
> /   -> output a literal "/"
> 9+ -> output the preference code for #9 according to the current style.
> ) -> output closing bracket of the super ')'.
>
> Other examples:
>
> c:min(maj7)[5+.9+] (suitable for american style) -> Cm(Maj7)(#5#9)
> c:min.maj[9+.5+]   (suitable jazz style).  -> C- delta stacked("9+","5+")
> c:min[9+/7+/5+]  or c:min[9+.7+.5+]    (banter style)   ->  C-
> super("9+/7+/5+")
>
> Note how these examples demonstrate that, in the proposal, layout of the
> chord is controlled by a combination of style and .ly source. Switching from
> banter to jazz is not as simple as changing the style, since alterations and
> decorations are also driven by the grammar of the .ly input. However, by
> using the parse tree of the original chord name, the user is given the power
> to control the output directly. which greatly simplifies the output
> conversion.
>
> Precise details of the new grammar are open for discussion, but I'll write
> up a proposal before I do it.
>
> Note how the examples show how the user is driving many important decisions
> like: what order the alterations go in; how and where the maj is displayed,
> where maj requires a 7th or not; which is more imporant (maj, min or aug),
> and how to deal with the specific exception case of  min(maj7) in each of
> the three systems.

Yes, this seems a sensible thing to leave in the hands of the user.

> I have managed to establish that "r1" in a chord context fires an event of
> some kind, but I'm not really sure which event and how to catch it. Strings
> also fire events that get junked. I'm significantly hampered by the fact
> that cygwin's GDB coredumps when it tries to load lily, so I can't really
> trace through code -- which is a significant problem for me right now. I
> need to spend some time playing with Cygwin/GDB versions to see if I can fix
> this.

Ouch.  I've seen some threads on this issue (pun intended) on the
Cygwin list.  Have you read those?

> I the meantime, if you could give me some hints as to where and how to catch
> the events fired by "r4" or by strings, I would be grateful.

Look at Rest_engraver::try_music (Music *m).  Consider:

    \score{ \chords { c r c:m } }

Jan.
   
-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org