3 language.pod -- state of the art mudela-vapourware.
7 [this document is slowly merged into the mudela doco, as the
8 implementation progresses. If you want to see our previous musings,
9 take out an old version of lilypond]
13 =head1 CONCRETE PROPOSALS
16 =head1 Decisions (Sat 1997-3-15, dommelpijpje no21)
18 \extract{ \from 2:3*4 \to 5 oboe }
24 It is difficult to make mistakes with typing now because you have to
25 tell LilyPond what it is dealing with
31 staff { music { identifier } }
33 I'm not sure on dropping this, I'm afraid it will make the language
34 less legible. Technically, dropping it is not very difficult (it will
35 introduce slight parser-source bloat)
37 What if the staff is extended to have some more blocks, all of which
38 can be declared? Like the score now:
47 This will only be readable if the Mudela-user rigidly uses hungarian,
50 Of course \key should take a \notename. In fact, I think we should
51 program the note intervals (which are now hardcoded for midi purposes)
52 To allow adaptation to other scales.
54 As simple fix, we might do key declarations:
56 \keybes= \key { bes es }
64 I want to give the user some access to the internals. Technically,
65 engravers/performers will happily typeset voices which mix lyrics and
66 notes, which combine stem requests and lyricreqs. I want to have a
68 \request { melodic name = 5, acc = -10
69 rhythmic ball=4 dots 2, lyric = "foobar" }
71 type of syntax. This is the most flexible input format possible, since
72 any valid LilyPond input can be made. This strongly implies tying
73 mudela to LilyPond. That I don't mind, but it hampers
74 portability. Suppose some commercial systems want to read mudela too.
76 =head2 Command placement:
85 This is a idea of mine: we could filter some request types from
90 \mel1 = \music { c-. d-. e-. f-. \meter {2*4} g-. a-. b.- c-. }
92 \m1 = \filter { "script_req" \mel1 }
93 \m2 = \filter { "command_req" \mel1 }
94 \m3 = \filter { "melodic_req" \mel1 }
95 \m3 = \filter { ("rhythmic_req") && (!"lyric_req") &&
96 ("stem_req" || "beam_req") \mel1 }
97 % syntax needs change. Clash with () slur?
99 \mel2 = \music { c c g g a a g2 }
101 \combined = \merge { \m1, \mel2 }
103 This means m1 contains the scripts, of \mel, \m2 only the meter
104 command surrounded by (essentially) some skips, and \m3 the notes
105 without scripts or meters. This could be a solution to the "command in
106 music vs. command with skip".
108 Combined with merging of requests, this would be a powerful tool. In
109 this example \combined is a combination of melody mel2 and the accents
112 This idea is for advanced users, but it would come in handy in urtext
115 include "mozart-horn.ly"
117 \m1 = \merge { \urmozart + \dennisbrain_interpretation }
118 \m2 = \merge { \urmozart + \barrytuckwell_interpretation }
121 =head2 Proposed operators:
125 || && ! filter syntax
131 \oboe = \music { ........................ }
133 \oboefragment = \extract { \from 5*2 \to 6*2 \music { \oboe } }