3 language.pod -- state of the art mudela-vapourware.
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.
16 I dislike vapourware. That's why I oppose to concrete plans on how to
17 do input for features we don't know how to produce on paper
21 A musical notation that is relatively easy to comprehend to both
22 programmers and non programmers. The final aim is to be able to
23 express what can be expressed in sheet music.
25 This document is intended to summarise the plans for mudela 2 (mudela
26 0 being mpp-input, and mudela-1 LilyPond input upto version 0.0.38).
27 Ideas for any further extensions (mudela 3, read total vapourware)
28 should be marked as such.
46 Possible to edit the layout without danger of changing the
47 original music. (fingerings, interpretation)
50 Simple music manipulations, such as transposing, creating a
51 score for individual instruments as well as for the conductor,
52 extracting short pieces from a longer one, glueing several shorter
53 pieces into a single score.
63 Mahlerian orchestral score
69 pop songs (lyrics + chords)
75 bach multivoice organ music.
78 short excerpts to be used in musicological publications.
86 When I say LilyPond input, I mean the final output of the parsing
87 step, which should be roughly the same as it is now: hierarchically,
101 Voice should stay the same:
116 We definitely need the concept of staff in the parser output, because
117 it is fundamental to LilyPond. I think the input language should
118 allow the user to do something like:
120 melody = { c d e f g }
122 %At this time I can't think of more than these stafftypes
123 staff { gregorian music { melody } }
124 staff { pianostaff music { melody } }
125 staff { melodic music { melody } }
126 staff { rhythmic music { melody } }
127 staff { lyric music { melody } } % silly, i admit.
129 The staff could also define what the instrument would be (both in
132 Moreover, if music {} in score equals staff, then how do we do multiple
135 We might be able to do without the staff{} construct, but I doubt if
136 it will make things easier.
147 It is difficult to make mistakes with typing now because you have to
148 tell LilyPond what it is dealing with
154 staff { music { identifier } }
156 I'm not sure on dropping this, I'm afraid it will make the language
157 less legible. Technically, dropping it is not very difficult (it will
158 introduce slight parser-source bloat)
160 What if the staff is extended to have some more blocks, all of which
161 can be declared? Like the score now:
170 This will only be readable if the Mudela-user rigidly uses hungarian,
175 I like it. Let's keep it in the language if we need it, it's a
176 universally accepted escape sequence.
180 I like the idea of <> vs. {}. Not because I think it is more clear,
181 but I dislike the word "music", I can't seem to find the proper word
182 for what "music" currently does, so I'd like to flush it.
184 I would like to point that both <> and {} are indicating a
185 hierarchy. I think, we should continue to allow them to nest. I still
186 have no preference what to use for what.
188 =head2 Command syntax
190 Braces on commands are here now, because the {} are the only nesting
191 braces. We need to avoid that, since the brace is overused as it
192 is. We don't like lisp that much. (the key is the only commands which
197 \bar "some args", "some more";
199 (note the ; ), which is a mix of perl and TeX.
201 Of course \key should take a \notename. In fact, I think we should
202 program the note intervals (which are now hardcoded for midi purposes)
203 To allow adaptation to other scales.
205 As simple fix, we might do key declarations:
207 \keybes= \key { bes es }
213 We could be even more rabid, and use '\rab' as \bar terminator.
215 Just kidding of course...
219 We might drop this {} argument altogether, by merely enforcing
220 that each "statement" (music,score,staff,chord) takes a LIST as
221 argument, and use the {} to group lists. This is admittedly perl. This
227 I want to give the user some access to the internals. Technically,
228 walkers/registers will happily typeset voices which mix lyrics and
229 notes, which combine stem requests and lyricreqs. I want to have a
231 \request { melodic name = 5, acc = -10
232 rhythmic ball=4 dots 2, lyric = "foobar" }
234 type of syntax. This is the most flexible input format possible, since
235 any valid LilyPond input can be made. This strongly implies tying
236 mudela to LilyPond. That I don't mind, but it hampers
237 portability. Suppose some commercial systems want to read mudela
242 the $ and @ were quick hacks, which suck badly. Replacing it by a
243 mechanism that switches the lexer automatically would be better, but
244 it is still error prone, and it hurts uniformity. What I would like
245 best is unified syntax, but this seems impossible since lyrics could
246 clash with notenames. If possible it would simplify the parser, the
247 scanner, and the explanation of the language.
252 'bes- sen sap % some lyric syllables
254 We can make one of the ' ` " a lyric-indication, but then we would
255 have to change the octave indication, eg.
265 And I am still not sure if it would be possible now, but I think this
266 is worthwile to investigate. Or we could replace @ by a
267 quote (take your pick) sign, which is a lot more intuitive.
269 The big question remaining is: do we want to add any more modes than
275 Even looser ideas: we can take a look at the perl wagon. It has numerous
276 inputmodes. What about:
293 If we free up $ @ from their current meaning, $ and @ could be used to
294 signify other things.
296 =head2 Concrete solution to lyric vs. note
302 is a valid lyric too. This implies that any bare string is checked if
303 it is a note. Now it prints an error if not, but I could change it to
304 assume it is a STRING (and can be reduced to lyric). Heck! I could
305 implement this tonight. We'd lose one mode! (after checking lexer
306 source) the only problem is preventing puctuation and the - and _ from
307 clashing with script symbols.
310 =head2 Command placement:
312 Mats is an arduous fan of having the commands inside music. I am
313 not. I see the Mudela music as something which can be plugged into
314 different staffs, transposed, translated in time, copied, quoted,
315 etc. Encouraging "inline" commands would be bad since they hinder this
316 reuse of mudela-isated music.
318 The way I figure it, the bad part is essentially counting
319 bars/wholes. Maybe we can get rid of it, by reinstalling the "mark"
322 I definitely want to avoid complicated logic ("Hey there is another
323 bar request, should we merge this bar with another staff's", this kind
324 of "smartness" makes a lot M$ software inconsistent) inside LilyPond,
325 by making the input unambiguous in this respect.
327 There is another complication: some symbols (bars) sometimes are
328 linked across staffs. I should first think of a way to do this in
329 LilyPond, before even considering a syntax.
331 [see also: filtering]
339 The syntax of /, * and : has to be settled, we have
341 - notes (1, 2, 4, 8 etc), which also can take 1*2/3 to do plets.
344 - multiple notes: 3*4
345 - abbreviations (not implemented) c4/4 or c4*4
346 - measure grouping, {2*4 3*4}
352 This is a idea of mine: we could filter some request types from
357 \mel1 = \music { c-. d-. e-. f-. \meter {2*4} g-. a-. b.- c-. }
359 \m1 = \filter { "script_req" \mel1 }
360 \m2 = \filter { "command_req" \mel1 }
361 \m3 = \filter { "melodic_req" \mel1 }
362 \m3 = \filter { ("rhythmic_req") && (!"lyric_req") &&
363 ("stem_req" || "beam_req") \mel1 }
364 % syntax needs change. Clash with () slur?
366 \mel2 = \music { c c g g a a g2 }
368 \combined = \merge { \m1, \mel2 }
370 This means m1 contains the scripts, of \mel, \m2 only the meter
371 command surrounded by (essentially) some skips, and \m3 the notes
372 without scripts or meters. This could be a solution to the "command in
373 music vs. command with skip".
375 Combined with merging of requests, this would be a powerful tool. In
376 this example \combined is a combination of melody mel2 and the accents
379 This idea is for advanced users, but it would come in handy in urtext
382 include "mozart-horn.ly"
384 \m1 = \merge { \urmozart + \dennisbrain_interpretation }
385 \m2 = \merge { \urmozart + \barrytuckwell_interpretation }
388 =head2 Proposed operators:
392 || && ! filter syntax
393 ++ concatenation of voices
397 =head2 C++ OOP like input.
399 I don't see the big win of this.
404 sc1.paper=mypaperdef;
406 We're not doing a programming language. In this syntax the parser has
407 to lookup what sc1 means, decide if it should copied shallow/deep,
408 decide if has a staff block, switch the mode after it finds that staff
409 takes music. May be I'm just ranting, but it looks hairy to
410 me. Remember that at this stage we're just filling structs.
412 In a distant future there might be a need for programming (are you
413 listening, Philip Glass?), but I think that would be something for
414 Mudela version 3. And I think using m4 (or something alike) would be
417 It might clear things up, if JCN told us what is so special about this
418 syntax (without the C++ looks).
422 Has to be done. How about:
424 \transpose { \from c \to g \music { ... }}
430 \oboe = \music { ........................ }
432 \oboefragment = \extract { \from 5*2 \to 6*2 \music { \oboe } }