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 =head1 CONCRETE PROPOSALS
  23
  24
  25 =head1 Decisions (Sat 1997-3-15, dommelpijpje no21)
  26
  27 =over 4
  28
  29 =item *
  30
  31 abbrev: [c2 c2]\noplet{1/2} (wat bout [c2 c2]1/2\noplet?),
  32
  33 =item *
  34
  35 abbrev: c4=16 (heu, =?),
  36
  37 =item *
  38
  39 plet === midi-note: c4*2/3; c4*385/384,
  40
  41 =item *
  42
  43 drop \music,
  44
  45 =item *
  46
  47 \meter compulsory in Simple mudela,
  48
  49 =item *
  50
  51 C<+> is  merge
  52
  53
  54 =item *
  55
  56         \extract{ \from 2:3*4 \to 5 oboe }
  57
  58 =back
  59
  60
  61
  62 =head1 THOUGHTS
  63
  64 =head2 Typing
  65
  66 It is difficult to make mistakes with typing now because you have to
  67 tell LilyPond what it is dealing with
  68
  69         staff { identifier }
  70
  71 versus
  72
  73         staff { music { identifier } }
  74
  75 I'm not sure on dropping this, I'm afraid it will make the language
  76 less legible. Technically, dropping it is not very difficult (it will
  77 introduce slight parser-source bloat)
  78
  79 What if the staff is extended to have some more blocks, all of which
  80 can be declared? Like the score now:
  81
  82         score {
  83                 a_staff_id
  84                 a_midi_id
  85                 a_paper_id
  86                 a_command_id
  87         }
  88
  89 This will only be readable if the Mudela-user rigidly uses hungarian,
  90 which he/she won't.
  91
  92 Of course \key should take a \notename. In fact, I think we should
  93 program the note intervals (which are now hardcoded for midi purposes)
  94 To allow adaptation to other scales.
  95
  96 As simple fix, we might do key declarations:
  97
  98         \keybes= \key { bes es }
  99
 100         \key{\keybes}
 101
 102
 103
 104 [LOOSE THOUGHT]
 105
 106 We might drop this {} argument altogether, by merely enforcing
 107 that each "statement" (music,score,staff,chord) takes a LIST as
 108 argument, and use the {} to group lists. This is admittedly perl. This
 109 is very sketchy.
 110
 111
 112 =head2 Requests
 113
 114 I want to give the user some access to the internals. Technically,
 115 engravers/performers will happily typeset voices which mix lyrics and
 116 notes, which combine stem requests and lyricreqs. I want to have a
 117
 118         \request { melodic name = 5, acc = -10
 119                 rhythmic ball=4 dots 2, lyric = "foobar" }
 120
 121 type of syntax. This is the most flexible input format possible, since
 122 any valid LilyPond input can be made. This strongly implies tying
 123 mudela to LilyPond. That I don't mind, but it hampers
 124 portability. Suppose some commercial systems want to read mudela too.
 125
 126 =head2 Command placement:
 127
 128 Mats is an arduous fan of having the commands inside music. I am
 129 not. I see the Mudela music as something which can be plugged into
 130 different staffs, transposed, translated in time, copied, quoted,
 131 etc. Encouraging "inline" commands would be bad since they hinder this
 132 reuse of typed music.
 133
 134 The way I figure it, the bad part is essentially counting
 135 bars/wholes. Maybe we can get rid of it, by reinstalling the "mark"
 136 commands.
 137
 138 I definitely want  to avoid complicated logic  ("Hey there is  another
 139 bar request, should we merge this bar with another staff's", this kind
 140 of "smartness" makes a  lot M$ software inconsistent) inside LilyPond,
 141 by making the input unambiguous in this respect.
 142
 143 There is another complication: some symbols (bars) sometimes are
 144 linked across staffs. I should first think of a way to do this in
 145 LilyPond, before even considering a syntax.
 146
 147
 148 =head2 Volta
 149
 150 uhh?
 151
 152 =head2 Filtering
 153
 154 This is a idea of mine: we could filter some request types from
 155 voices,
 156
 157 eg:
 158
 159         \mel1 = \music { c-. d-. e-. f-. \meter {2*4} g-. a-. b.- c-. }
 160
 161         \m1 = \filter { "script_req" \mel1 }
 162         \m2 = \filter { "command_req" \mel1 }
 163         \m3 = \filter { "melodic_req" \mel1 }
 164         \m3 = \filter { ("rhythmic_req") && (!"lyric_req") &&
 165                 ("stem_req" || "beam_req") \mel1 }
 166                 % syntax needs change. Clash with () slur?
 167
 168         \mel2 = \music { c c g  g a a g2 }
 169
 170         \combined = \merge { \m1, \mel2  }
 171
 172 This means m1 contains the scripts, of \mel, \m2 only the meter
 173 command surrounded by (essentially) some skips, and \m3 the notes
 174 without scripts or meters. This could be a solution to the "command in
 175 music vs. command with skip".
 176
 177 Combined with merging of requests, this would be a powerful tool. In
 178 this example \combined is a combination of melody mel2 and the accents
 179 of \mel1.
 180
 181 This idea is for advanced users, but it would come in handy in urtext
 182 editions:
 183
 184         include "mozart-horn.ly"
 185
 186         \m1 = \merge { \urmozart + \dennisbrain_interpretation }
 187         \m2 = \merge { \urmozart + \barrytuckwell_interpretation }
 188
 189
 190 =head2 Proposed operators:
 191
 192 Just ideas:
 193
 194         || && !         filter syntax
 195         +               merging of voices
 196
 197 =head2 Quoting
 198
 199 Difficult. Hmm...
 200
 201         \oboe = \music { ........................ }
 202
 203         \oboefragment = \extract { \from 5*2 \to 6*2 \music { \oboe } }
 204
 205