Dear all,
Over the last three years I have been preparing a professional music edition
of a major work for flute and piano using MusiXTeX, and I thought I should
share some of my experiences and make suggestions for improvement. I am
fully aware that preparing a score print-ready and to professional standards
is not what MusiXTeX is designed for in the first place. I am pretty
confident, however, that most of my suggestions would not be difficult to
implement.
Two sample pages of my edition can be previewed here:
https://www.notenbuch.de/Grosse-Konzertsonate-op-85-Kuhlau-Friedrich-CFS4709
-1551022.html#
(Click on the cover illustration.)
It is an Urtext edition, so the appearance of the score was precisely
determined by my editorial choices, and I would have wished that no
compromise of the "not-100%-correct-but-easier-to-typeset" kind had been
necessary; but see section "1. Beams" below .
For the "orthography" of musical typesetting, I predominantly relied on
Elaine Gould's standard reference book "Behind Bars" (London 2011), plus the
occasional look into first-rate engraved editions (mainly Henle, sometimes
Schott).
1. Beams
Beams are probably the one item where it is downright impossible to achieve
a fully professional output (as described in Gould 17-21) with MusiXTeX, and
my guess is that solving this problem would not even be too difficult, at
least within the musixvbm package which I used. The current syntax of
specifying an initial pitch and a slope (as in "\ibbu1g{-2}") leads to the
following problems:
(i) It is often impossible to avoid beams beginning or ending between
stave-lines, which is orthographically incorrect (ultimately for reasons of
readability). (A ubiquitous problem which MusiXTeX obviously knows nothing
about. You will notice a couple of instances already in the two sample pages
linked above.)
(ii) For very long beams, slope 1 may be far too much, while slope 0 may be
orthographically incorrect. (A rare problem but quite serious whenever it
does occur; I had to live with a couple of harsh compromises in my edition.)
To solve this, the syntax of musixvbm beams would have to be reorganised. A
possible approach might be: There are only three orthographically correct
positions for the beginning and the end of a beam: sitting on, centred on,
or hanging from, a stave-line. If the user had the possibility of choosing
line and position independently for beginning and end of the beam (i.e.,
specifying four parameters instead of two), problems (i) and (ii) would
vanish. (Obviously, the two parameters for line and position could be
combined into one, but this may lead to a less intuitive syntax.)
Lastly, (iii), multiple beams should be implemented according to the
established rules: Roughly speaking, the 16th beam goes on the "inside" of
the 8th beam while 32nd and higher beams are added on the "outside" (64th
beams may need a different design altogether, at least as an option; see
Gould 18).
2. Slurs
I was able to make use of musixps, but only "by coincidence", since in my
score no complicated cases occurred. There were, e.g., no S-shaped slurs to
connect notes on different staves. (Dirty tricks like putting together an
S-shaped slur from two or three regular slurs may be possible, though.)
Basically, the musixps slurs looked beautiful, but there were some issues:
(i) I would have wished to have more influence on the two Bezier control
points. If I had been able to choose both of them independently and within a
sensibly large range, I could have realised every shape of slur needed in my
score without limitation. Currently, psslur does not really support the more
asymmetric shapes of slurs (the parameter \psslurangul was of virtually no
use to me).
(ii) It would be desirable to have influence on line thickness, too; a
slightly thicker line would seem preferable to me.
(iii) Both MusiXTeX's and musixps's handling of slurs over line breaks works
only for horizontal slurs (i.e., ties, mostly), so I had to break all slurs
manually (and undo and redo this every time I decided to move a line break
elsewhere). It would not be difficult to devise an algorithm which yields
acceptable results in a high percentage of cases; I am, however, aware that
this would probably require a two-pass system since the termination pitch of
the slur needs to be known to MusiXTeX already by the time it is processing
the line break.
(iv) Finding out earlier about the existence of the command \Nosluradjust
would have saved me from much cursing . But that's entirely my own fault.
(I do believe, however, that automatisations of the \Sluradjust kind
generally tend to create far more, and far more serious, problems than they
solve.)
3. Hairpins
musixps unfortunately did not implement that "hairpins are the thickness of
a stave-line" (Gould 103); I had to use musixps, though, in order to have
access to long and open hairpins which MusiXTeX's font-based hairpins do not
offer. (Incidentally, I never understood why those fonts were not extended
to include hairpins up to the full length of a line and open hairpins as
needed at line breaks.)
4. Accidentals
In order to keep the number of page turnings to a minimum, you want to make
good use of each page, so many lines of a score will be tightly fit and
every point of horizontal space is valuable. MusiXTeX's accidentals could be
optimised in that respect:
(i) The characters have a sumptuous width. There is more than one line in my
score where the points of additional horizontal space gained by a slightly
slimmer design of accidentals would have helped me a lot. (\smallaccid or
\varaccid is not an option in a professional score).
(ii) By MusiXTeX default, sharps and naturals are set rather far apart from
their notehead which is not only a waste of space but often results in an
accidental being closer to the preceding note than to the one it refers to.
Flats on the other hand are too close. I moved sharps by default 0.5pt
closer to their notehead, naturals 1pt closer, flats 0.3pt farther apart;
where ledger lines were present, accidentals were moved 1.4pt to the left.
(Since the existence of ledger lines is determined by pitch and clef,
MusiXTeX could probably do this automatically).
(iii) There were hardly any cases where I could have used \lsh etc., but I
made heavy use of macros of the type
\def\osh#1#2{\rlap{\kern -#1pt\sh{#2}}}
in order to arrange accidentals before chords.
(iv) When the \generalsignature consists of flats, these could be grouped
considerably closer together at the beginning of each line.
5. Stave spacing
More often than not, I had to adjust the stave distance at the beginning of
a new line, depending on how much space was needed for dynamics symbols or
notes or stems far outside the staves. I used macros of the type
\def\alaligned#1#2{\stoppiece\def\interfacteur{#1}\setinterinstrument1{#2pt}
\contpiece}
for this. Unfortunately \interfacteur also affects the distance of the solo
part from the piano, so in order to change only the distance of the piano
staves, the second parameter had to be reduced by 6 times the increment of
the first parameter (e.g., coding \alaligned{12}6 or .d{13}0 to replace my
default .d{11}{12}.) There may be a better way of doing this. I am just
noting the point since MusiXTeX seems to assume that the typesetter will
want to keep stave spacing more or less constant throughout the score; from
Goold 488f, however, we learn otherwise.
6. Dot design
Duration dots (as used by \pt etc.) need to be bigger than staccato dots
(Goold 116). I had a bar in my edition (1st movment, measure 250) where both
concurred, and the resulting appearance is a bit unclear and unpleasant.
7. Ledger lines
"It is important that ledger lines are visibly thicker than stave-lines"
(Gould 26). This can easily be achieved by saying, e.g., \def\hlthick{0.4pt}
at the beginning of the document. If I am not wrong, musixdoc does not
mention this possibility.
8. Staccato command
On a more anecdotal note: In the preamble of all my MusiXTeX files, I
redefine for obvious reasons
\let\ute\ust \let\ust\upz \let\usst\uppz etc.
Decades ago, I even discussed this with Daniel Taupin, MusiXTeX's designer,
via e-mail; I was not able to talk him out of his conviction that
"pizzicato" was the correct term for what the rest of the world calls
"staccato".
I hope this contributes to future improvement of MusiXTeX! Do not hesitate
to contact me for more details.
Wilfried Lingenberg
-------------------------------
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to
https://tug.org/mailman/listinfo/tex-music
