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 =back
  96
  97 =item *
  98
  99 drop \music,
 100
 101 =item *
 102
 103 \meter compulsory in Simple mudela,
 104
 105 =item *
 106
 107 C<+> is  merge
 108
 109
 110 =item *
 111
 112         \extract{ \from 2:3*4 \to 5 oboe }
 113
 114 =back
 115
 116
 117
 118 =head1 THOUGHTS
 119
 120 =head2 Typing
 121
 122 It is difficult to make mistakes with typing now because you have to
 123 tell LilyPond what it is dealing with
 124
 125         staff { identifier }
 126
 127 versus
 128
 129         staff { music { identifier } }
 130
 131 I'm not sure on dropping this, I'm afraid it will make the language
 132 less legible. Technically, dropping it is not very difficult (it will
 133 introduce slight parser-source bloat)
 134
 135 What if the staff is extended to have some more blocks, all of which
 136 can be declared? Like the score now:
 137
 138         score {
 139                 a_staff_id
 140                 a_midi_id
 141                 a_paper_id
 142                 a_command_id
 143         }
 144
 145 This will only be readable if the Mudela-user rigidly uses hungarian,
 146 which he/she won't.
 147
 148 Of course \key should take a \notename. In fact, I think we should
 149 program the note intervals (which are now hardcoded for midi purposes)
 150 To allow adaptation to other scales.
 151
 152 As simple fix, we might do key declarations:
 153
 154         \keybes= \key { bes es }
 155
 156         \key{\keybes}
 157
 158
 159
 160 [LOOSE THOUGHT]
 161
 162 We might drop this {} argument altogether, by merely enforcing
 163 that each "statement" (music,score,staff,chord) takes a LIST as
 164 argument, and use the {} to group lists. This is admittedly perl. This
 165 is very sketchy.
 166
 167
 168 =head2 Requests
 169
 170 I want to give the user some access to the internals. Technically,
 171 walkers/registers will happily typeset voices which mix lyrics and
 172 notes, which combine stem requests and lyricreqs. I want to have a
 173
 174         \request { melodic name = 5, acc = -10
 175                 rhythmic ball=4 dots 2, lyric = "foobar" }
 176
 177 type of syntax. This is the most flexible input format possible, since
 178 any valid LilyPond input can be made. This strongly implies tying
 179 mudela to LilyPond. That I don't mind, but it hampers
 180 portability. Suppose some commercial systems want to read mudela
 181 too.
 182
 183
 184 =head2 Command placement:
 185
 186 Mats is an arduous fan of having the commands inside music. I am
 187 not. I see the Mudela music as something which can be plugged into
 188 different staffs, transposed, translated in time, copied, quoted,
 189 etc. Encouraging "inline" commands would be bad since they hinder this
 190 reuse of typed music.
 191
 192 The way I figure it, the bad part is essentially counting
 193 bars/wholes. Maybe we can get rid of it, by reinstalling the "mark"
 194 commands.
 195
 196 I definitely want  to avoid complicated logic  ("Hey there is  another
 197 bar request, should we merge this bar with another staff's", this kind
 198 of "smartness" makes a  lot M$ software inconsistent) inside LilyPond,
 199 by making the input unambiguous in this respect.
 200
 201 There is another complication: some symbols (bars) sometimes are
 202 linked across staffs. I should first think of a way to do this in
 203 LilyPond, before even considering a syntax.
 204
 205
 206 =head2 Volta
 207
 208 uhh?
 209
 210 =head2 Filtering
 211
 212 This is a idea of mine: we could filter some request types from
 213 voices,
 214
 215 eg:
 216
 217         \mel1 = \music { c-. d-. e-. f-. \meter {2*4} g-. a-. b.- c-. }
 218
 219         \m1 = \filter { "script_req" \mel1 }
 220         \m2 = \filter { "command_req" \mel1 }
 221         \m3 = \filter { "melodic_req" \mel1 }
 222         \m3 = \filter { ("rhythmic_req") && (!"lyric_req") &&
 223                 ("stem_req" || "beam_req") \mel1 }
 224                 % syntax needs change. Clash with () slur?
 225
 226         \mel2 = \music { c c g  g a a g2 }
 227
 228         \combined = \merge { \m1, \mel2  }
 229
 230 This means m1 contains the scripts, of \mel, \m2 only the meter
 231 command surrounded by (essentially) some skips, and \m3 the notes
 232 without scripts or meters. This could be a solution to the "command in
 233 music vs. command with skip".
 234
 235 Combined with merging of requests, this would be a powerful tool. In
 236 this example \combined is a combination of melody mel2 and the accents
 237 of \mel1.
 238
 239 This idea is for advanced users, but it would come in handy in urtext
 240 editions:
 241
 242         include "mozart-horn.ly"
 243
 244         \m1 = \merge { \urmozart + \dennisbrain_interpretation }
 245         \m2 = \merge { \urmozart + \barrytuckwell_interpretation }
 246
 247
 248 =head2 Proposed operators:
 249
 250 Just ideas:
 251
 252         || && !         filter syntax
 253         ++              concatenation of voices
 254         +               merging of voices
 255
 256 =head2 Quoting
 257
 258 Difficult. Hmm...
 259
 260         \oboe = \music { ........................ }
 261
 262         \oboefragment = \extract { \from 5*2 \to 6*2 \music { \oboe } }
 263
 264