4 language.pod -- state of the art mudela-vapourware.
12 here are some thoughts on the language. Most of the examples are in
13 pseudo current mudela. Some stuff gratuitously taken from your mails.
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
22 A musical notation that is relatively easy to comprehend to both
23 programmers and non programmers. The final aim is to be able to
24 express what can be expressed in sheet music.
41 Possible to edit the layout without danger of changing the
42 original music. (fingerings, interpretation)
45 Simple music manipulations, such as transposing, creating a
46 score for individual instruments as well as for the conductor,
47 extracting short pieces from a longer one, glueing several shorter
48 pieces into a single score.
58 Mahlerian orchestral score
64 pop songs (lyrics + chords)
70 bach multivoice organ music.
73 short excerpts to be used in musicological publications.
81 When I say LilyPond input, I mean the final output of the parsing
82 step, which should be roughly the same as it is now: hierarchically,
96 Voice should stay the same:
111 We definitely need the concept of staff in the parser output, because
112 it is fundamental to LilyPond. I think the input language should
113 allow the user to do something like:
115 melody = { c d e f g }
117 %At this time I can't think of more than these stafftypes
118 staff { gregorian music { melody } }
119 staff { pianostaff music { melody } }
120 staff { melodic music { melody } }
121 staff { rhythmic music { melody } }
122 staff { lyric music { melody } } % silly, i admit.
124 The staff could also define what the instrument would be (both in
127 Moreover, if music {} in score equals staff, then how do we do multiple
130 We might be able to do without the staff{} construct, but I doubt if
131 it will make things easier.
133 =head1 CONCRETE PROPOSAL
135 Any optional request/modifier should follow the note/rest-name/lyric:
139 [a()a]()a a[( a)]( a)
141 the []() construct doesn't look nice. We might make an exception for
148 It is difficult to make mistakes with typing now because you have to
149 tell LilyPond what it is dealing with
155 staff { music { identifier } }
157 I'm not sure on dropping this, I'm afraid it will make the language
158 less legible. Technically, dropping it is not very difficult (it will
159 introduce slight parser-source bloat)
161 What if the staff is extended to have some more blocks, all of which
162 can be declared? Like the score now:
171 This will only be readable if the Mudela-user rigidly uses hungarian,
176 I like it. Let's keep it in the language if we need it, it's a
177 universally accepted escape sequence.
181 I like the idea of <> vs. {}. Not because I think it is more clear,
182 but I dislike the word "music", I can't seem to find the proper word
183 for what "music" currently does, so I'd like to flush it.
185 I would like to point that both <> and {} are indicating a
186 hierarchy. I think, we should continue to allow them to nest. I still
187 have no preference what to use for what.
189 =head2 Command syntax
191 Braces on commands are here now, because the {} are the only nesting
192 braces. We need to avoid that, since the brace is overused as it
193 is. We don't like lisp that much. (the key is the only commands which
198 \bar "some args", "some more";
200 (note the ; ), which is a mix of perl and TeX.
202 Of course \key should take a \notename. In fact, I think we should
203 program the note intervals (which are now hardcoded for midi purposes)
204 To allow adaptation to other scales.
206 As simple fix, we might do key declarations:
208 \keybes= \key { bes es }
216 We might drop this {} argument altogether, by merely enforcing
217 that each "statement" (music,score,staff,chord) takes a LIST as
218 argument, and use the {} to group lists. This is admittedly perl. This
224 I want to give the user some access to the internals. Technically,
225 walkers/registers will happily typeset voices which mix lyrics and
226 notes, which combine stem requests and lyricreqs. I want to have a
228 \request { melodic name = 5, acc = -10
229 rhythmic ball=4 dots 2, lyric = "foobar" }
231 type of syntax. This is the most flexible input format possible, since
232 any valid LilyPond input can be made. This strongly implies tying
233 mudela to LilyPond. That I don't mind, but it hampers
234 portability. Suppose some commercial systems want to read mudela
239 the $ and @ were quick hacks, which suck badly. Replacing it by a
240 mechanism that switches the lexer automatically would be better, but
241 it is still error prone, and it hurts uniformity. What I would like
242 best is unified syntax, but this seems impossible since lyrics could
243 clash with notenames. If possible it would simplify the parser, the
244 scanner, and the explanation of the language.
249 'bes- sen sap % some lyric syllables
251 We can make one of the ' ` " a lyric-indication, but then we would
252 have to change the octave indication, eg.
262 And I am still not sure if it would be possible now, but I think this
263 is worthwile to investigate. Or we could replace @ by a
264 quote (take your pick) sign, which is a lot more intuitive.
266 The big question remaining is: do we want to add any more modes than
272 Even looser ideas: we can take a look at the perl wagon. It has numerous
273 inputmodes. What about:
290 If we free up $ @ from their current meaning, $ and @ could be used to
291 signify other things.
293 =head2 Concrete solution to lyric vs. note
299 is a valid lyric too. This implies that any bare string is checked if
300 it is a note. Now it prints an error if not, but I could change it to
301 assume it is a STRING (and can be reduced to lyric). Heck! I could
302 implement this tonight. We'd lose one mode! (after checking lexer
303 source) the only problem is preventing puctuation and the - and _ from
304 clashing with script symbols.
307 =head2 Command placement:
309 Mats is an arduous fan of having the commands inside music. I am
310 not. I see the Mudela music as something which can be plugged into
311 different staffs, transposed, translated in time, copied, quoted,
312 etc. Encouraging "inline" commands would be bad since they hinder this
313 reuse of typed music.
315 The way I figure it, the bad part is essentially counting
316 bars/wholes. Maybe we can get rid of it, by reinstalling the "mark"
319 I definitely want to avoid complicated logic ("Hey there is another
320 bar request, should we merge this bar with another staff's", this kind
321 of "smartness" makes a lot M$ software inconsistent) inside LilyPond,
322 by making the input unambiguous in this respect.
324 There is another complication: some symbols (bars) sometimes are
325 linked across staffs. I should first think of a way to do this in
326 LilyPond, before even considering a syntax.
335 The syntax of /, * and : has to be settled, we have
337 - notes (1, 2, 4, 8 etc)
340 - multiple notes: 3*4
341 - abbreviations (not implemented) c4/4 or c4*4
345 This is a idea of mine: we could filter some request types from
350 \mel1 = \music { c-. d-. e-. f-. \meter {2*4} g-. a-. b.- c-. }
352 \m1 = \filter { "script_req" \mel1 }
353 \m2 = \filter { "command_req" \mel1 }
354 \m3 = \filter { "melodic_req" \mel1 }
355 \m3 = \filter { ("rhythmic_req") && (!"lyric_req") &&
356 ("stem_req" || "beam_req") \mel1 }
357 % syntax needs change. Clash with () slur?
359 \mel2 = \music { c c g g a a g2 }
361 \combined = \merge { \m1, \mel2 }
363 This means m1 contains the scripts, of \mel, \m2 only the meter
364 command surrounded by (essentially) some skips, and \m3 the notes
365 without scripts or meters. This could be a solution to the "command in
366 music vs. command with skip".
368 Combined with merging of requests, this would be a powerful tool. In
369 this example \combined is a combination of melody mel2 and the accents
372 This idea is for advanced users, but it would come in handy in urtext
375 include "mozart-horn.ly"
377 \m1 = \merge { \urmozart + \dennisbrain_interpretation }
378 \m2 = \merge { \urmozart + \barrytuckwell_interpretation }
381 =head2 Proposed operators:
385 || && ! filter syntax
386 ++ concatenation of voices
390 =head2 C++ OOP like input.
392 I don't see the big win of this.
397 sc1.paper=mypaperdef;
400 We're not doing a programming language. In this syntax the parser has
401 to lookup what sc1 means, decide if it should copied shallow/deep,
402 decide if has a staff block, switch the mode after it finds that staff
403 takes music. May be I'm just ranting, but it looks hairy to
404 me. Remember that at this stage we're just filling structs.
406 In a distant future there might be a need for programming (are you
407 listening, Philip Glass?), but I think that would be something for
408 Mudela version 3. And I think using m4 (or something alike) would be
413 Has to be done. How about:
415 \transpose { \from c \to g \music { ... }}
421 \oboe = \music { ........................ }
423 \oboefragment = \extract { \from 5*2 \to 6*2 \music { \oboe } }