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 here are some thoughts on the language. Most of the examples are in
  12 pseudo current mudela.  Some stuff gratuitously taken from your mails.
  13
  14
  15 =head1 NOTE
  16
  17 I dislike vapourware. That's why I oppose to concrete plans on how to
  18 do input for features we don't know how to produce on paper
  19
  20 =head1 REQUIREMENTS
  21
  22 =head2 Parser output
  23
  24 When I say LilyPond input, I mean the final output of the parsing
  25 step, which should be roughly the same as it is now: hierarchically,
  26 using pseudo syntax
  27
  28         Score {
  29                 Midi_def
  30                 Paper_def
  31                 Staff [multiple] {
  32                         Voices
  33                         Stafftype
  34                         (instrument)
  35                 }
  36         }
  37
  38
  39 Voice should stay the same:
  40
  41         Voice {
  42                 Voice_elements
  43         }
  44
  45 and
  46
  47         Voice_elements {
  48                 requests
  49         }
  50
  51
  52 =head2 Staffs
  53
  54 We definitely need the concept of staff in the parser output, because
  55 it is fundamental to LilyPond.  I think the input language should
  56 allow the user to do something like:
  57
  58         melody = { c d e f g }
  59
  60         %At this time I can't think of more than these stafftypes
  61         staff { gregorian music { melody } }
  62         staff { pianostaff music { melody } }
  63         staff { melodic music { melody } }
  64         staff { rhythmic music { melody } }
  65         staff { lyric music { melody } }        % silly, i admit.
  66
  67 The staff could also define what the instrument would be (both in
  68 print and in MIDI)
  69
  70 Moreover, if music {} in score equals staff, then how do we do multiple
  71 voices on one staff?
  72
  73 We might be able to do without the staff{} construct, but I doubt if
  74 it will make things easier.
  75
  76 =head1 CONCRETE PROPOSALS
  77
  78
  79 =head1 Decisions (Sat 1997-3-15, dommelpijpje no21)
  80
  81 =over 4
  82
  83 =item *
  84
  85 abbrev: [c2 c2]\noplet{1/2} (wat bout [c2 c2]1/2\noplet?),
  86
  87 =item *
  88
  89 abbrev: c4=16 (heu, =?),
  90
  91 =item *
  92
  93 plet === midi-note: c4*2/3; c4*385/384,
  94
  95 =item *
  96
  97 drop \music,
  98
  99 =item *
 100
 101 \meter compulsory in Simple mudela,
 102
 103 =item *
 104
 105 C<+> is  merge
 106
 107
 108 =item *
 109
 110         \extract{ \from 2:3*4 \to 5 oboe }
 111
 112 =back
 113
 114
 115
 116 =head1 THOUGHTS
 117
 118 =head2 Typing
 119
 120 It is difficult to make mistakes with typing now because you have to
 121 tell LilyPond what it is dealing with
 122
 123         staff { identifier }
 124
 125 versus
 126
 127         staff { music { identifier } }
 128
 129 I'm not sure on dropping this, I'm afraid it will make the language
 130 less legible. Technically, dropping it is not very difficult (it will
 131 introduce slight parser-source bloat)
 132
 133 What if the staff is extended to have some more blocks, all of which
 134 can be declared? Like the score now:
 135
 136         score {
 137                 a_staff_id
 138                 a_midi_id
 139                 a_paper_id
 140                 a_command_id
 141         }
 142
 143 This will only be readable if the Mudela-user rigidly uses hungarian,
 144 which he/she won't.
 145
 146 Of course \key should take a \notename. In fact, I think we should
 147 program the note intervals (which are now hardcoded for midi purposes)
 148 To allow adaptation to other scales.
 149
 150 As simple fix, we might do key declarations:
 151
 152         \keybes= \key { bes es }
 153
 154         \key{\keybes}
 155
 156
 157
 158 [LOOSE THOUGHT]
 159
 160 We might drop this {} argument altogether, by merely enforcing
 161 that each "statement" (music,score,staff,chord) takes a LIST as
 162 argument, and use the {} to group lists. This is admittedly perl. This
 163 is very sketchy.
 164
 165
 166 =head2 Requests
 167
 168 I want to give the user some access to the internals. Technically,
 169 walkers/registers will happily typeset voices which mix lyrics and
 170 notes, which combine stem requests and lyricreqs. I want to have a
 171
 172         \request { melodic name = 5, acc = -10
 173                 rhythmic ball=4 dots 2, lyric = "foobar" }
 174
 175 type of syntax. This is the most flexible input format possible, since
 176 any valid LilyPond input can be made. This strongly implies tying
 177 mudela to LilyPond. That I don't mind, but it hampers
 178 portability. Suppose some commercial systems want to read mudela
 179 too.
 180
 181
 182 =head2 Command placement:
 183
 184 Mats is an arduous fan of having the commands inside music. I am
 185 not. I see the Mudela music as something which can be plugged into
 186 different staffs, transposed, translated in time, copied, quoted,
 187 etc. Encouraging "inline" commands would be bad since they hinder this
 188 reuse of typed music.
 189
 190 The way I figure it, the bad part is essentially counting
 191 bars/wholes. Maybe we can get rid of it, by reinstalling the "mark"
 192 commands.
 193
 194 I definitely want  to avoid complicated logic  ("Hey there is  another
 195 bar request, should we merge this bar with another staff's", this kind
 196 of "smartness" makes a  lot M$ software inconsistent) inside LilyPond,
 197 by making the input unambiguous in this respect.
 198
 199 There is another complication: some symbols (bars) sometimes are
 200 linked across staffs. I should first think of a way to do this in
 201 LilyPond, before even considering a syntax.
 202
 203
 204 =head2 Volta
 205
 206 uhh?
 207
 208 =head2 Filtering
 209
 210 This is a idea of mine: we could filter some request types from
 211 voices,
 212
 213 eg:
 214
 215         \mel1 = \music { c-. d-. e-. f-. \meter {2*4} g-. a-. b.- c-. }
 216
 217         \m1 = \filter { "script_req" \mel1 }
 218         \m2 = \filter { "command_req" \mel1 }
 219         \m3 = \filter { "melodic_req" \mel1 }
 220         \m3 = \filter { ("rhythmic_req") && (!"lyric_req") &&
 221                 ("stem_req" || "beam_req") \mel1 }
 222                 % syntax needs change. Clash with () slur?
 223
 224         \mel2 = \music { c c g  g a a g2 }
 225
 226         \combined = \merge { \m1, \mel2  }
 227
 228 This means m1 contains the scripts, of \mel, \m2 only the meter
 229 command surrounded by (essentially) some skips, and \m3 the notes
 230 without scripts or meters. This could be a solution to the "command in
 231 music vs. command with skip".
 232
 233 Combined with merging of requests, this would be a powerful tool. In
 234 this example \combined is a combination of melody mel2 and the accents
 235 of \mel1.
 236
 237 This idea is for advanced users, but it would come in handy in urtext
 238 editions:
 239
 240         include "mozart-horn.ly"
 241
 242         \m1 = \merge { \urmozart + \dennisbrain_interpretation }
 243         \m2 = \merge { \urmozart + \barrytuckwell_interpretation }
 244
 245
 246 =head2 Proposed operators:
 247
 248 Just ideas:
 249
 250         || && !         filter syntax
 251         ++              concatenation of voices
 252         +               merging of voices
 253
 254 =head2 Quoting
 255
 256 Difficult. Hmm...
 257
 258         \oboe = \music { ........................ }
 259
 260         \oboefragment = \extract { \from 5*2 \to 6*2 \music { \oboe } }
 261
 262