--- /dev/null
+=head1 NAME
+
+language.pod -- state of the art mudela-vapourware.
+
+=head1 SYNOPSIS
+
+(damn pod)
+
+=head1 DESCRIPTION
+
+here are some thoughts on the language. Most of the examples are in
+pseudo current mudela. Some stuff gratuitously taken from your mails.
+
+=head1 NOTE
+
+I dislike vapourware. That's why I oppose to concrete plans on how to
+do input for features we don't know how to produce on paper
+
+=head1 AIM
+
+A musical notation that is relatively easy to comprehend to both
+programmers and non programmers. The final aim is to be able to
+express what can be expressed in sheet music.
+
+=over 5
+
+=item *
+play pieces
+
+=item *
+typeset the pieces
+
+=back
+
+further requirements:
+
+=over 5
+
+=item *
+Possible to edit the layout without danger of changing the
+original music. (fingerings, interpretation)
+
+=item *
+Simple music manipulations, such as transposing, creating a
+score for individual instruments as well as for the conductor,
+extracting short pieces from a longer one, glueing several shorter
+pieces into a single score.
+
+=back
+
+Pieces could be:
+
+
+=over 5
+
+=item *
+Mahlerian orchestral score
+
+=item *
+piano pieces
+
+=item *
+pop songs (lyrics + chords)
+
+=item *
+gregorian chant (?)
+
+=item *
+bach multivoice organ music.
+
+=item *
+short excerpts to be used in musicological publications.
+
+=back
+
+=head1 REQUIREMENTS
+
+=head2 Parser output
+
+When I say LilyPond input, I mean the final output of the parsing
+step, which should be roughly the same as it is now: hierarchically,
+using pseudo syntax
+
+ Score {
+ Midi_def
+ Paper_def
+ Staff [multiple] {
+ Voices
+ Stafftype
+ (instrument)
+ }
+ }
+
+
+Voice should stay the same:
+
+ Voice {
+ Voice_elements
+ }
+
+and
+
+ Voice_elements {
+ requests
+ }
+
+
+=head2 Staffs
+
+We definitely need the concept of staff in the parser output, because
+it is fundamental to LilyPond. I think the input language should
+allow the user to do something like:
+
+ melody = { c d e f g }
+
+ %At this time I can't think of more than these stafftypes
+ staff { gregorian music { melody } }
+ staff { pianostaff music { melody } }
+ staff { melodic music { melody } }
+ staff { rhythmic music { melody } }
+ staff { lyric music { melody } } % silly, i admit.
+
+The staff could also define what the instrument would be (both in
+print and in MIDI)
+
+Moreover, if music {} in score equals staff, then how do we do multiple
+voices on one staff?
+
+We might be able to do without the staff{} construct, but I doubt if
+it will make things easier.
+
+=head1 THOUGHTS
+
+=head2 Typing
+
+It is difficult to make mistakes with typing now because you have to
+tell LilyPond what it is dealing with
+
+ staff { identifier }
+
+versus
+
+ staff { music { identifier } }
+
+I'm not sure on dropping this, I'm afraid it will make the language
+less legible. Technically, dropping it is not very difficult (it will
+introduce slight parser-source bloat)
+
+What if the staff is extended to have some more blocks, all of which
+can be declared? Like the score now:
+
+ score {
+ a_staff_id
+ a_midi_id
+ a_paper_id
+ a_command_id
+ }
+
+This will only be readable if the Mudela-user rigidly uses hungarian,
+which he/she won't.
+
+=head2 Backslash
+
+I like it. Let's keep it in the language if we need it, it's a
+universally accepted escape sequence.
+
+=head2 Braces
+
+I like the idea of <> vs. {}. Not because I think it is more clear,
+but I dislike the word "music", I can't seem to find the proper word
+for what "music" currently does, so I'd like to flush it.
+
+I would like to point that both <> and {} are indicating a
+hierarchy. I think, we should continue to allow them to nest. I still
+have no preference what to use for what.
+
+=head2 Command syntax
+
+Braces on commands are here now, because the {} are the only nesting
+braces. We need to avoid that, since the brace is overused as it
+is. We don't like lisp that much. (the key is the only commands which
+really needs {} now)
+
+How about
+
+ \bar "some args", "some more";
+
+(note the ; ), which is a mix of perl and TeX.
+
+Of course \key should take a \notename. In fact, I think we should
+program the note intervals (which are now hardcoded for midi purposes)
+To allow adaptation to other scales.
+
+As simple fix, we might do key declarations:
+
+ \keybes= \key { bes es }
+
+ \key{\keybes}
+
+
+
+[LOOSE THOUGHT]
+
+We might drop this {} argument altogether, by merely enforcing
+that each "statement" (music,score,staff,chord) takes a LIST as
+argument, and use the {} to group lists. This is admittedly perl. This
+is very sketchy.
+
+
+=head2 Requests
+
+I want to give the user some access to the internals. Technically,
+walkers/registers will happily typeset voices which mix lyrics and
+notes, which combine stem requests and lyricreqs. I want to have a
+
+ \request { melodic name = 5, acc = -10
+ rhythmic ball=4 dots 2, lyric = "foobar" }
+
+type of syntax. This is the most flexible input format possible, since
+any valid LilyPond input can be made. This strongly implies tying
+mudela to LilyPond. That I don't mind, but it hampers
+portability. Suppose some commercial systems want to read mudela
+too.
+
+=head2 Lexer modes
+
+the $ and @ were quick hacks, which suck badly. Replacing it by a
+mechanism that switches the lexer automatically would be better, but
+it is still error prone, and it hurts uniformity. What I would like
+best is unified syntax, but this seems impossible since lyrics could
+clash with notenames. If possible it would simplify the parser, the
+scanner, and the explanation of the language.
+
+What about:
+
+ bes c d e f % notes
+ 'bes- sen sap % some lyric syllables
+
+We can make one of the ' ` " a lyric-indication, but then we would
+have to change the octave indication, eg.
+
+ _bes % lower
+ ^bes % higher
+
+or
+
+ +bes % higher
+ -bes % lower
+
+And I am still not sure if it would be possible now, but I think this
+is worthwile to investigate. Or we could replace @ by a
+quote (take your pick) sign, which is a lot more intuitive.
+
+The big question remaining is: do we want to add any more modes than
+lyric and note?
+
+
+[LOOSE THOUGHT]
+
+Even looser ideas: we can take a look at the perl wagon. It has numerous
+inputmodes. What about:
+
+ lyric << ENDLYRIC
+
+ bes- sen- sap
+
+ ENDLYRIC
+
+ music << ENDMUSIC
+
+ c d e f g
+
+ ENDMUSIC
+
+
+[LOOSE THOUGHT]
+
+If we free up $ @ from their current meaning, $ and @ could be used to
+signify other things.
+
+=head2 Concrete solution to lyric vs. note
+
+I think
+
+ "lyric"
+
+is a valid lyric too. This implies that any bare string is checked if
+it is a note. Now it prints an error if not, but I could change it to
+assume it is a STRING (and can be reduced to lyric). Heck! I could
+implement this tonight. We'd lose one mode! (after checking lexer
+source) the only problem is preventing puctuation and the - and _ from
+clashing with script symbols.
+
+
+=head2 Command placement:
+
+Mats is an arduous fan of having the commands inside music. I am
+not. I see the Mudela music as something which can be plugged into
+different staffs, transposed, translated in time, copied, quoted,
+etc. Encouraging "inline" commands would be bad since they hinder this
+reuse of typed music.
+
+The way I figure it, the bad part is essentially counting
+bars/wholes. Maybe we can get rid of it, by reinstalling the "mark"
+commands.
+
+I definitely want to avoid complicated logic ("Hey there is another
+bar request, should we merge this bar with another staff's", this kind
+of "smartness" makes a lot M$ software inconsistent) inside LilyPond,
+by making the input unambiguous in this respect.
+
+There is another complication: some symbols (bars) sometimes are
+linked across staffs. I should first think of a way to do this in
+LilyPond, before even considering a syntax.
+
+
+=head2 Volta
+
+uhh?
+
+=head2 Numbers
+
+The syntax of /, * and : has to be settled, we have
+
+ - notes (1, 2, 4, 8 etc)
+ - meter 2*4
+ - plet 2/3
+ - multiple notes: 3*4
+ - abbreviations (not implemented) c4/4 or c4*4
+
+=head2 Filtering
+
+This is a idea of mine: we could filter some request types from
+voices,
+
+eg:
+
+ \mel1 = \music { c-. d-. e-. f-. \meter {2*4} g-. a-. b.- c-. }
+
+ \m1 = \filter { "script_req" \mel1 }
+ \m2 = \filter { "command_req" \mel1 }
+ \m3 = \filter { "melodic_req" \mel1 }
+ \m3 = \filter { ("rhythmic_req") && (!"lyric_req") &&
+ ("stem_req" || "beam_req") \mel1 }
+ % syntax needs change. Clash with () slur?
+
+ \mel2 = \music { c c g g a a g2 }
+
+ \combined = \merge { \m1, \mel2 }
+
+This means m1 contains the scripts, of \mel, \m2 only the meter
+command surrounded by (essentially) some skips, and \m3 the notes
+without scripts or meters. This could be a solution to the "command in
+music vs. command with skip".
+
+Combined with merging of requests, this would be a powerful tool. In
+this example \combined is a combination of melody mel2 and the accents
+of \mel1.
+
+This idea is for advanced users, but it would come in handy in urtext
+editions:
+
+ include "mozart-horn.ly"
+
+ \m1 = \merge { \urmozart + \dennisbrain_interpretation }
+ \m2 = \merge { \urmozart + \barrytuckwell_interpretation }
+
+
+=head2 Proposed operators:
+
+Just ideas:
+
+ || && ! filter syntax
+ ++ concatenation of voices
+ + merging of voices
+
+
+=head2 C++ OOP like input.
+
+I don't see the big win of this.
+
+ score sc1= melody;
+ sc1.staff{\verse};
+ sc1.staff{<\b1 \b2>}
+ sc1.paper=mypaperdef;
+
+
+We're not doing a programming language. In this syntax the parser has
+to lookup what sc1 means, decide if it should copied shallow/deep,
+decide if has a staff block, switch the mode after it finds that staff
+takes music. May be I'm just ranting, but it looks hairy to
+me. Remember that at this stage we're just filling structs.
+
+In a distant future there might be a need for programming (are you
+listening, Philip Glass?), but I think that would be something for
+Mudela version 3. And I think using m4 (or something alike) would be
+just as convenient.
+
+=head2 Transposition
+
+Has to be done. How about:
+
+ \transpose { \from c \to g \music { ... }}
+
+=head2 Quoting
+
+Difficult. Hmm...
+
+ \oboe = \music { ........................ }
+
+ \oboefragment = \extract { \from 5*2 \to 6*2 \music { \oboe } }
+
+
projects / lilypond.git / commitdiff