Hi, 1. Beams The main issues are (a) and (b) in follows: (a) floating point arithmetic such as multiplication and division to get the proper slope. For a long time I have no solution for it, however, just now, I googled on this issue and found a LaTeX2e package 'fp'. (I am now very far apart from LaTeX in my daily life for over 20 years so I know very little about recent status of LaTeX.) For my first impression, the fp package seems to be useable even on plain TeX with some small hacks to disable LaTeX2e-specific macros (\NeedsTeXFormat and \ProvidesPackage). We are not allowed to modify fp package itself for our side due to LPPL; therefore, we should put out some new idea to disable them without any harm, including consideration of MusiXTeX use inside a LaTeX document.
(b) syntax. Current MusiXTeX (and all versions from its birth) deals with the beam slope value in a dynamic macro \b@p, and the final destination is a \count, i.e., integer. I think it will be a bit challenging to enable handling floating-point values: This needs modification to \setmaxinstruments (T.115 and later) and then harmful to many existing macros (especially musixps due to it's drastic diversion of use of registers). But I think it will be possible (by someone) and it is worth implementing to pass a floating point values as-is (for example, using some temporary macro instead of \count). An all-new implementation might be desirable but we should aware that it requires consensus to lost compatibility with legacy score sources and related programs such as PMX. Sincerely, Hiroaki ----- Original Message ----- > From: "Wilfried Lingenberg" <[email protected]> > To: <[email protected]> > Date: Wed, 28 Dec 2022 21:16:32 +0100 > Subject: [Tex-music] Tales from typesetting a professional edition with > MusiXTeX > > > 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 > > > > > > ------------------------------- > [email protected] mailing list > If you want to unsubscribe or look at the archives, go to > https://tug.org/mailman/listinfo/tex-music ------------------------------- [email protected] mailing list If you want to unsubscribe or look at the archives, go to https://tug.org/mailman/listinfo/tex-music
