<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
_______________________________________________
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
