I have finally joined gnu-music-discuss, so it's no longer necessary
to CC me when writing to the list.
> [EMAIL PROTECTED] writes:
> > > > 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.
> >
> > Well, the question of what the word "really" mean is a sticky one. Do
> > you really care what machine language gets generated when you write
> > "if"? Do you want the C tutorial to explain that an "if" will
> > generate the following assembly language? There are different levels
> > of what "if" means. Which one is "real".
> >
> > The most valuable one for a C programmer is to understand how "if"
> > affects the execution of blocks of code---not which machine language
> > instructions cause this effect.
> >
> > Similarly, in Mudela, I think the most valuable thing for a music
> > typesetter to know is that typing "a4" produces a quarter note a.
> > This is the proper level of comprehension for this task, in my
> > opinion.
>
> After thinking some more, I think you are right. Maybe it would
> suffice to explain that note names are not a fundamental part of the
> language because they can be changed (and really are converted to a
> bunch of numbers very quickly).
>
> Nitpick: a4 does not *produce* a quarter note a, it *is* a quarter
> note a. Converting it produces the *graphic* note (a symbol) or a
> *midi* note: there is a subtle difference in declaring things (like a4
> does) and converting them, which is the function of the \paper and
> \midi block.
Counter-nitpick: When I write "a4" I there's no quarter note anywhere.
There are only bits in the computer. What is a quarter note exactly?
Is it sound? Is it the graphic representation in standard musical
notation? Maybe it's an abstraction that links the way we write music
and the way we perform it? I'm not sure what the answer is, but it
seems clear to me that bits in a computer are not a quarter note.
Perhaps the best way to describe what happens is to say that a4
represents a quarter note.
Now why does anyone care that "a4" represents a quarter note? I doubt
most people care because they are impressed by the existence of an
abstract representation; they care because when they run the right
programs, they can produce audio or graphical output of the quarter
note. They care because when they process the representation in the
appropriate way, a quarter note is produced. The production of a
quarter note is the purpose of the representation.
When you write a program in C, the word "if" doesn't do anything. The
behavior of the C program is a function of the compiler which converts
that "if" into machine language. Does this mean that it's wrong to
say that the word "if" produces certain behavior? I don't think it's
really wrong. A C program is not very interesting in the abstract as
a representation of an algorithm, and that's certainly not how people
regard C programs.
> > I think that one effective way to fight this kind of misunderstanding
> > would be to give a more complete example. There are ZERO examples of
> > music with a key signature in the tutorial, so I think it's no
> > surprise that I didn't understand this.
>
> Thanks for pointing that out. Your mail made me think about some of
> the tutorials that I know.
>
> On the one hand, you have the C progrmming lanugage, which starts with
> full-blown example that is lengthily discussed. The advantage of this
> is that the user is given an example that really works. The
> disadvantage is that the example features a lot of stuff that can't be
> explained in detail.
In the case of documenting Mudela, I think you can give an example
which really works AND also reveals all of the basic information
needed by someone who wants to enter a melody, or maybe even a series
of chords. Despite all that, it will still be simple enough not to
overwhelm, and it will be possible to give a reasonable explanation of
what everything does. True, a user may not appreciate all of the
details of the language, but she will know enough to get started.
There's less that a basic user needs to know about Mudela than there
is that a basic user needs to know about C. Also I think that if a
basic user is faced by a Mudela text and the printed output, most of
the elements in this basic Mudela program will be obvious.
> But your approach (avoiding internals), might be difficult to maintain
> once advanced stuff (like notation contexts) have to be explained.
> They basically _are_ internals that you manipulate quite directly from
> the input language.
Well, I guess in part it depends on how internal the internals really
are. I mean, if the internals happen to be externals as well, then
you have to document them.
The commands \musicalpitch and \duration seem to be VERY internal.
The only reason you need to know \musicalpitch exists is so that you
can redefine note names. There seems to be no reason to know about
\duration. I think things like this need not appear in the tutorial
at all.
Other things seem to be less internal. To change anything about the
output appearance it seems like I have to write my own translator, for
example. Since some people might need this, perhaps it should be in
the tutorial, but at the end. I think you should introduce internals
like this in sections at the end and only as needed. I also think
that a less direct interface should be provided. If I want bar
numbering, I have to write something like
Staff = \translator {
\type "Line_group_engraver_group";
defaultclef = violin;
\consists "Bar_engraver";
\consists "Clef_engraver";
\consists "Key_engraver";
\consists "Local_key_engraver";
\consists "Time_signature_engraver";
\consists "Staff_sym_engraver";
\consists "Collision_engraver";
\consists "Rest_collision_engraver";
\consists "Bar_column_engraver";
\consists "Bar_number_engraver";
\consists "Separating_line_group_engraver";
\accepts "Voice";
}
BTW, apparently
include "bar-numbering.ly"
produces errors about mismatched braces, even though there aren't any.
Clearly something is wrong. If I start my input with
include "bar-numbering.ly"
I get the message
foo2.ly:2:26: error: parse error, expecting `'='':
include "bar-numbering.ly"
]]warning: braces don't match
Kind of strange, considering that if I simply insert the text, it
gives no error.
If I put
include "bar-numbering.ly"
in the \paper{} command, then I get
foo2.ly:44:26: error: parse error, expecting `'='':
include "bar-numbering.ly"
]]
foo2.ly:7:6: warning: score contains errors; will not process it:
So what should the average user need to know? I think that the
average user should know how to either type
include "bar-numbering.ly"
or maybe
\numberbars
or some other shorthand. Perhaps the internals should be more hidden
than they presently are.
(Out of curiosity, is it normal to print the number at the start of
every line? I would have expected printing a number every "n" bars to
be more normal.)
> I was probably thinking: whenever the design is OK, the design
> decisions are apparent from the chosen design. (and behaviour can be
> derived from internal design).
It's possible that this is true, but I suspect that most of the time,
the design decisions are only really apparent to people who don't know
the system very well and really understand it. To someone who isn't a
computer programmer, it will be hard to understand the design
decisions that underlie the choice of certain data structures or data
representations.
> > Right now if I type
> > \melodic{ a4 b2 c8 d16 e32 }
> > it sure looks to me like the things between the braces are notes.
> > They have pitch and duration. Lyrics are more than just syllables for
> > the same reason:
> > \lyrics{ foo4 bar2 }
> >
> > So it seems misleading to name them \pitches and \syllables. The
> > content of the argument will be notes (with both pitch and duration)
> > or lyrics (with both syllables and duration).
>
> OK. I was just nitpicking about internals: \melodic and \lyric
> change the way in which strings are interpreted; the strings are only
> about the pitch/syllable, not about their durations. But, granted
>
> \notes
> \lyrics
>
> looks cuter.
I think I understand the internals in this case, and I still think
that it is misleading to name it \pitches and \syllables. Why?
Because the two modes have the purpose of enabling me to represent
notes and lyrics. It makes sense to name things according to what
their purpose and function is rather than according to how they
achieve that function. If you name things according to how they work
then you need to change the name every time you change how they work.
If you name things according to what they do, this isn't a concern.
Inside \melodic, the parsing works to enable the convenient entering
of notes. It so happens that no special duration handling is
necessary. I'll bet if it was, you would implement it. (If you
someday discover a reason for special duration parsing you'll probably
implement it.)
> > > > > > verb(a&@&@&TSI|{[ % a word
> > > > > > 1THtrhortho % not a "word"
> > > > > > Leise DOEXPAND(Fl\)DOEXPAND("u\)ss{}teren meine Sapfe % 4 words
> > > also starts with a letter, so the quote is included in the string. If
> > > you want quotes in the syllable, you do
> > >
> > > "bla\"bla"
> > >
> >
> > Yes, this works, though the escaping of strings was never
> > documented...., and a plain
> > bla"blah
> > works too.
> >
> > I just went and reread the statement, though, and realized that I'm
> > wrong. It says: Every sequence of non-digit and non-white characters
> > starting with an alphabetic character or the code(_) is considered a
> > word. So starting with `` is forbidden. (This is the natural way of
> > introducing quotes in TeX output.) These characters can be introduced
> > by using the " to quote.
> >
> > And she said "``quoted" passsage starts, and ends''
>
> OK. That looks like a fine passage for putting into to the refman.
I've discovered that the illegal example which appears in the tutorial
actually works fine:
\lyric { 'got8 me on my knees4, Le-8 lie! }
It's kind of interesting that "'got8" which is rather odd works ok,
but "``bla" fails. (Note that this example has two illegalities in
it, not just the first word.)
So I went and tried to read the lexer code (even though I don't know
anything about flex). It seems that the relevant portions are:
A [a-zA-Z]
AA {A}|_
PUNCT [?!:']
ACCENT \\[`'"^]
NATIONAL [\001-\006\021-\027\031\036\200-\377]
TEX {AA}|-|{PUNCT}|{ACCENT}|{NATIONAL}
LYRICS ({AA}|{TEX})[^0-9 \t\n\f]*
Now a bit of trying things out has lead me to the following statement
of what a lyric really is:
It starts with any either
an alphabetic character, or an
one of ?!:'
^A through ^F or ^Q through ^W (Feeding ^A to my TeX produced an error)
one of these 2 character combinations: \' \` \" \^
So for example:
\"foo
^Afoo
'foo
!foo
?foo
are all lyrics that work ok. So I think I can safely return to my
original statement that the documented claim is wrong. Lyrics need
not start with an alphabetic character as claimed.
I must admit that the way things are currently set up seems
overcomplicated. Why not admit as a lyric anything that doesn't start
with a number or whitespace and doesn't look like "\" followed by an
alphabetic character?
> > > > +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'?
> >
> > What I meant by scope was that it marks the region that the context
> > holds. So for example, if you write
> > \melodic a4 b4 c4
> > then the note mode context ends after the first note. (I may not be
> > using the word "context" the way you used it, but I didn't know what
> > else to say.) Writing
> > \melodic { a4 b4 c4 }
> > marks the scope of the note mode.
>
>
> I find it easier to think in terms of grammar;
>
> \melodic
>
> takes one `argument' of type music, and music is like
>
> music: '<' musiclist '>'
> | '{' musiclist '}'
> | note
> ;
>
> >The only reason to write the braces
> > in this case is so that \melodic knows how far to go.
>
> No, that is not true.
>
> \melodic \type Staff< .. >
>
> is valid as well (and normal jargon in mudela.)
I agree that it's better to understand this your way.
Note, however, that you just contradicted yourself by saying that
\melodic takes an argument from the grammar and then presenting an
example where the argument didn't come from that grammar.
Also note that the only reason to write the braces is to group them
together into an argument so that \melodic knows how far to go. That
this can also be achieved with < > characters doesn't change this.
But what about a statement like
\score{ ...stuff... }
What are the brackets doing there? Is this yet another data type: the
list commands of the form '\keyword argument'? Or are the { and }
characters just showing scope of the \score? What is the best
interpretation?
One thing which seems very difficult to understand is what can go on
the right side of the statement:
foo = RHS;
and under what circumstances you can then write "\foo" without getting
an error. Do you have any insight on how to explain in a simple way
what is going on here? The tutorial presently has a big long list of
what RHS can be, but nothing about where \foo can subsequently appear.
And a big long list is, of course, not the ideal way to characterize
the possibilities for RHS.
Here's an attempt at a grammar describing these things. I havn't
tried to integrate \type or \property into this. They seem to have
their own idiosyncratic syntax.
argument: real | integer | musiclist | assignlist | musiclist
statementlist | arglist
argseq: argument
argseq argument
arglist: { argseq }
statement: \identifier
\keyword argument
\keyword argseq ;
statementseq: statement statementseq
statement
statementlist: { statementseq }
assignment: string = statement ;
assignseq: assignseq assignment
assignment
assignlist: { assignseq }
musicseq: musiclist
musicseq musiclist
musiclist: { musicsequence }
< musicsequence >
note
statement
mudelafile: statement mudelafile
assignment mudelafile
So then I have the types taken by various keywords:
\score statmentlist
\paper assignlist
\header assignlist
\melodic musiclist
\lyrics arglist (??)
One last remark: yodl converts
code(%{)
into
\texttt{\%\texttt{\{}}
which produces a font error in latex and typesets the { in the wrong
font. I don't know why, but \texttt seems incapable of producing {.
It would seem preferable to produce
\verb!%{!
or maybe
\begin{verbatim}%{\end{verbatim}
instead. Or alternatively, figure out how to get the { to come out in
the right font.
And here's a distantly related question: is there anything I can do
with MIDI files on a Sun workstation? I have surfed the web but been
unable to determine the answer to this question.
