]> git.donarmstrong.com Git - lilypond.git/blob - Documentation/language.pod
partial: 1.0.1.jcn
[lilypond.git] / Documentation / language.pod
1 =head1 NAME
2
3 language.pod -- state of the art mudela-vapourware.
4
5 =head1 DESCRIPTION
6
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]
10
11 =head1 REQUIREMENTS
12
13 =head1 CONCRETE PROPOSALS
14
15
16 =head1 Decisions (Sat 1997-3-15, dommelpijpje no21)
17
18         \extract{ \from 2:3*4 \to 5 oboe }
19
20 =head1 THOUGHTS
21
22 =head2 Typing
23
24 It is difficult to make mistakes with typing now because you have to
25 tell LilyPond what it is dealing with
26
27         staff { identifier }
28
29 versus
30
31         staff { music { identifier } }
32
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)
36
37 What if the staff is extended to have some more blocks, all of which
38 can be declared? Like the score now:
39
40         score {
41                 a_staff_id
42                 a_midi_id
43                 a_paper_id
44                 a_command_id
45         }
46
47 This will only be readable if the Mudela-user rigidly uses hungarian,
48 which he/she won't.
49
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.
53
54 As simple fix, we might do key declarations:
55
56         \keybes= \key { bes es }
57
58         \key{\keybes}
59
60
61
62 =head2 Requests
63
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
67
68         \request { melodic name = 5, acc = -10
69                 rhythmic ball=4 dots 2, lyric = "foobar" }
70
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.
75
76 =head2 Command placement:
77
78
79 =head2 Volta
80
81 uhh?
82
83 =head2 Filtering
84
85 This is a idea of mine: we could filter some request types from
86 voices,
87
88 eg:
89
90         \mel1 = \music { c-. d-. e-. f-. \meter {2*4} g-. a-. b.- c-. }
91
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?
98
99         \mel2 = \music { c c g  g a a g2 }
100
101         \combined = \merge { \m1, \mel2  }
102
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".
107
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
110 of \mel1.
111
112 This idea is for advanced users, but it would come in handy in urtext
113 editions:
114
115         include "mozart-horn.ly"
116
117         \m1 = \merge { \urmozart + \dennisbrain_interpretation }
118         \m2 = \merge { \urmozart + \barrytuckwell_interpretation }
119
120
121 =head2 Proposed operators:
122
123 Just ideas:
124
125         || && !         filter syntax 
126
127 =head2 Quoting
128
129 Difficult. Hmm...
130
131         \oboe = \music { ........................ }
132
133         \oboefragment = \extract { \from 5*2 \to 6*2 \music { \oboe } }
134
135