[EMAIL PROTECTED] writes:
> [I am taking the discussion to gnu-music-discuss--hope you don't mind]
>
> I don't mind. Should I join this list? (I'm not on it right now.)
>
that might be go idea.
> > > It claims in the tutorial that d''4. is really shorthand for:
> > > \musicalpitch { 1 2 0 } \duration { 2 1 }
> > > If this is true, then why do I get an error message when I substitute
> > > the above for d''4? Obviously something more is going on.
> >
> > Yes. I have to twiddle some more to get that working.
>
> But is d''4 shorthand for something else, or not? I mean, if it's
> really just a shorthand, then the long form will work automatically.
It is converted internally to
< \noterequest { \pitch { 1 2 0 } \duration { 2 1} }
>
(where the \blah is just to give you an idea what's happening). It is
not really a shorthand (yet).
>
> BTW, how is '*3' written in the duration?
>
in the source its a separate plet field. The \duration {} doesn '
support it, mainly because I put it in to implement \breve and \longa
> > > Here are my thoughts about a tutorial and reference manual. The
> > > purpose of the tutorial should be to get people using the program as
> > > fast as possible. I think that explaining details of the internals
> > > (such as \musicalpitch and \duration) should not be done at all in the
> > > tutorial.
> >
> > I put it in to demonstrate what you people are really working with.
> > But maybe it ought to be in the reference manual.
> >
>
> But when I write [a4 b c d] I'm not "really" working with
> \musicalpitch and \duration. Those are hidden and basically
> irrelevant internals. Under what circumstances will an ordinary user
> need to even know about the existence of \musicalpitch and \duration?
> As far as I can tell, the one time when the existence of \musicalpitch
> becomes apparent is when I try to write my own language.ly. And I've
> only seen \duration used for defining \breve and \longa. Evidently
> it's so internal that it doesn't even appear in the init files. So
> why would Joe Composer need to know about it?
>
Because c4 and a2 are part of the `appearance' of the language. Who
would care if in C someone decided to rename the if keyword to IF?
(To me), the important part is what it all really means. cis is just a
name, as is `do', as is `cSharp'. I want people to understand what
they're doing.
You make me wonder if the tutorial is the right place to have such
musings, but I still would like to make the point somewhere.
I am afraid, that I don't make clear what is actually happening,
then people will start asking questions like
4.2: Why do I have to type the accidentals to the note if I specified them?
Take this example
cis cis
Independently of how it was written and what the current key was, you
would say that you are playing and reading "two C-sharp" notes. We
have tried to make the language somewhat context-free. Of course sheet
music is not context-free. Unfortunately, sheet music is also 2
dimensional, and ASCII is not.
Technically it would be feasible to have the Interpreting phase do
tricky things to add (or leave out) the accidentals, but we think that
it is impractical: it hampers the readability and portability of your
source, since you need LilyPond to fill in the details and actually
make sense of it.
> > Do you think so? Jan and I had some discussion over this (it used to
> > be after the pitch & duration section) ... I was reluctant to use
> > \relative, because it adds another level of complexity to the examples.
> > That's why I moved it to the end.
>
> Well, I think \relative is pretty useful for writing music. It's
> something that people who are writing music will want to know about.
> Keep in mind that the normal use of the tutorial will be to read as
> little as possible, so you should try to organize things in the order
> of how important it is for someone to know about feature X. You
> don't have to try to change all the examples to use it, but I think
> you should introduce it earlier and feel free to use it in examples
> after introducing it. Another thing which disturbed me about the
> tutorial was frequent forward referencing. Ideally a tutorial should
OK.
> >
> > The \blah { } commmands (as you would call them), or constructs are
> > different. To me the \blah is like a function, and what's in braces
> > is like an argument.
> >
> > \type { c4 }
> > \type c4
> > \type < c4 >
> >
> > are all valid.
> >
> > What is behind \blah in \blah{} typically is also examined by the
> > parser, and what is in \blah ... ; is usually just put dumped into
> > some strings, and examined during the interpretation phase.
>
> Well, mostly it seemed reasonable. The way I wrote it was that
> commands like \melodic take a single argument which can be "c4", or a
> {} grouping of music or a <> grouping of music. That makes sense to
> me.
>
> But then I see these commands \musicalpitch{ x y z } and \duration{ x
> y } and \script{ "foo" x y z ... }. These commands don't fit either
> documented pattern, nor do they fit the grammar that appears in the
> reference manual.
The grammar is for the Music part only (which is where most people
will be typing.) The \musicalpitch and \script {} stuff belongs in a
`advanced' mudela section. And again, they are not commands in the
programming language sense.
> > And then there are keywords, which are connected because every
> > \commmand and every \prefix{} construction uses a \keyword
> >
> > I do not like the syntax with `;', but we used to have a
> >
> > \meter {2/4}
>
> So is it the case that all the commands used to take arguments
> surrounded by braces, but that the for some commands, the syntax has
> been relaxed and the use of ';' introduced? Some commands still use
> the old syntax (like \script, \duration, and \musicalpitch)?
>
> If I write
> \score{
> \melodic{ a b c} ;
> \paper{}
> }
>
> and getting an error from the ;. This was puzzling. If you keep the
> ; I think there should be more flexibility about a few extra ; every
> so often. The error message is "parse error" which is vague enough
> that someone could spend a long time trying to figure out why their
> apparently correct code doesn't parse.
>
> > syntax, which also had problems (you get a lot of braces, and if you
> > forget one, hell still breaks loose). Ideally, I would want to have a
> >
> > \property Staff.meter = "2/4"
> >
> > probably, but I fear that this is too much work right now. (Plus Mats
> > would get all angry, because that would move much musicality out of
> > the language ;-)
>
> It looks like a lot to type.
>
Yup. But we could make it into some sort of abbreviation. And it
makes the language (and syntax) cleaner.
>
> > > After doing 'make dvi' and getting part way through refman.yo before a
> > > fatal error, I did make dvi again. The result is and endless loop of
> > > error messages, which is surely not the right behavior:
> >
> > This is a problem with YODL. What version of YODL do you use ?
> > Platform? Does installing GNU diff utils help? I know that YODL
> > doesn't really work well on my IRIX box.
>
> Well, I upgraded from 2.6 to 2.7 of the GNU diff utils and did
> something that I thought would induce the problem. The problem didn't
> occur, so maybe that fixed it. I have yodl 1.31.1 btw and am running
> under Solaris 2.6.
OK. I run Solaris 2.6 over here too, and have no trouble
> > Perhaps \melody and \lyrics is better than what we have, but I would
> > like to have some more comments. (And I would like to hear Jan's
> > comments; he'll be back in a week or so.)
>
> Well, another possibility might be "\notes" and "\lyrics" which seems
> even more direct. They match up neatly with the names of the modes
> and they also clearly state their contents ("look cute"). (Also
> "\melody" could be misleading if you're typing the work of Schoenberg
> in....)
A note has a duration too, so maybe \pitches and \syllables is better.
>
> > > verb(a&@&@&TSI|{[ % a word
> > > 1THtrhortho % not a "word"
> > > Leise DOEXPAND(Fl\)DOEXPAND("u\)ss{}teren meine Sapfe % 4 words
> > > _ _ _ _ % 4 words: 4 spaces
> > > ))
> > >
> > > COMMENT(Well, " seems to present some problems. Also `` seems to be
> > > problematic. So the above statement isn't quite right. Unless these
> > > characters are considered to be "white")
> >
> > I think the statements are correct, only YODL needs some fooling
> > (DOEXPAND) to get the ouptut right.
>
> No, the statements are false. I did extensive testing with lilypond
> as I was rewriting refman.yo to confirm my suspicions or to produce
> guesses about what was going on.
>
> If I write a lyric like: "foo" then the quotes disappear in the
> output. If I write `"foo' the quote disappears, I think. But `foo"'
> seems to keep its quote. If I write ``foo'' (with 4 quote characters)
> I get an error message. I couldn't find any way to introduce quotes
> systematically into my song lyrics (if I happened to want them). The
> handling of quotes is definitely screwy. It seems like the proper
> behavior is the documented behavior, but it's not what I see. In
> other words, the " shouldn't even be special. I suppose this might be
> confusing for entering commands, but I don't know if there are any
> commands that will be used for lyrics where the need to omit quotes
> might be confusing. (I'm using version 1.0.4 for my tests btw.)
>
It is not in the outdated ref manual, but a lyric syllable is like
string duration
where string can be
"in quotes"
StartingWithALetter
Confusingly,
EndingWithAQuote"
also starts with a letter, so the quote is included in the string. If
you want quotes in the syllable, you do
"bla\"bla"
(I think.)
> > > dit(code(\grouping) var(durationlist)) Sets the metric structure of
> > > the measure.
> > > COMMENT(elaboration is needed here.)
> >
> > again, the corresponding implementation needs rewriting, not the
> > manual.
> >
> > For the rest, your changes look like an improvement to me. But are
> > some subtle errors on the precise meaning of commands/syntax in some
> > places. Do you want to know them know (or can I put your patch in
> > ?).
>
> If you can tell me what the error are, I'm interested in knowing them.
> Or you could correct refman.yo and just send me diffs so I can see
> what you've changed. I'm hoping to avoid spending any time working on
> it for a few days, though, so I will not be sending a revised
> refman.yo any time soon.
OK. Then I'll put
> > You can also send in a patch to Documentation/topdocs/AUTHORS.yo
> > if you wish.
>
> --- AUTHORS.yo~ Wed Sep 2 04:22:47 1998
> +++ AUTHORS.yo Fri Sep 4 08:29:29 1998
> @@ -22,6 +22,8 @@
> misc bugfixes, some Beam and Stem code.
> it()nemail(David R. Linn)([EMAIL PROTECTED]),
> Mailing list maintenance.
> +it()nemail(Adrian Mariano)([EMAIL PROTECTED]),
> + Parts of Reference manual, tutorial, and vocabulary.data.
OK. Be forewarned though: the tutorial is going to be Tech Report at
the CS department over here (Authors: me and Jan), so if you oppose to
being published without being on the front page you might want to hold
back your patches.
> +Pairs of braces `code({)' and `code(})' or pairs of angle brackets
> +`code(<)' and `code(>)' are used to identify the scope
> +of contexts and enable the construction of hierarchical structure.
What do you mean by `scope'?
> +dit(code(\clear))
> +
> +dit(code(\clef) var(clefname)) Sets the current clef. The argument
> +is the name of the clef. Possibilities are code(bass), code(alto),
> +and code(treble). Treble clef is the default.
not completely. Arvid made it accept all kinds of strings.
> +
> +dit(code(\key) var(pitch)) Change key signature to that of var(pitch)-major.
> +
> +dit(code(\keysignature) var(notelist))
pitchlist. A note has a duration too.
> +dit(code(\partial) var(duration)) Specify that the first measure of
> +the music lasts only for the specified duration.
> +
> +dit(code(\paper) code({) [ code(linewidth = )var(width)code(;) ] code(}))
> +Appears in a score block to indicate that the music should be printed.
> +The line width can be set to -1. in order to prevent justification of
> +small fragments of music, or the width can be specified explicitly
> +using code(\cm), code(\in), code(\mm), or code(\pt) to specify the
> +units.
not entirely, \paper opens up a scope. You can have arbitrary
\paper {
key = val;
}
> +dit(code(\version) var(string)) Specify the version of Lilypond that
> +a file was written for. The argument is the version number,
> +for example code("1.0.4").
this is the version number of the language, not of Lilypond.
--
Han-Wen Nienhuys, [EMAIL PROTECTED] ** GNU LilyPond - The Music Typesetter
http://www.cs.uu.nl/people/hanwen/lilypond/index.html
