Hello Don and all,
In my simple tests so far, PMX so modified produces a proper MIDI file
(!!!), but of course MusiXTeX needs more attention. Simply including \\input
file:///\\input musixuad\ in the PMX file doesn't work, maybe because PMX
automatically includes musixmad. But simply commenting out \input musixmad
in the TeX file doesn't work either, due to the place where PMX puts \input
musixuad in the TeX file.
Simply change line 22098 of pmx2515.for:
write(11,'(a)')sq//'input musixuad'
instead of
write(11,'(a)')sq//'input musixmad'
if PMX finds over 13 instruments.
Latter input musixmad will ignore itself by line 20 of it.
I designed musixuad for both overlay of musixadd/musixmad
and standalone use.
That's where this stands at the moment. One thing that still dampens my
enthusiasm is the alleged incompatibility of musixuad with type K postscript
slurs. However, when I include such slurs in my simple test file (appended),
it still goes through (???).
PS slur type K macro (musixps.tex) not only overrides the definitions
of slurs and others but also steals some of already allocated slur
registers without any warnings.
Please see musixps.tex line 100-109.
Stealing registers seems to be simply due to conventional TeX's
limitation --- max 255 registers.
Now we can use e-TeX, so I think this musixps.tex specification is
out of date.
I think musixps.tex should be modified to allocate ALL the needed
registers using \newdimen, NOT \let. And thus musixps.tex should
be dependent on e-TeX (cannot be run on conventional TeX).
Another solution is to make musixps.tex obey \maxinstruments/
\maxslurs(newly installed into kernel.. see the last part) at the
moment of inclusion, etc.
Another problem: after input musixps.tex, the maximum slur numbers
is limited only 10 (see line 98 [EMAIL PROTECTED]@n) and this cannot
be increased anymore because of the internal bit-flags logic of
musixps.tex.
If we wants 11 or more type K slurs at the same moment, musixps.tex
must be greatly modified. (see line 164: [EMAIL PROTECTED])
I once tried to make the internal logic flexibly extendable,
but I found musixps was too artistically optimized. It was
beyond my skill.
Anyway, some hard work may satisfy our immediate demand.
However, if we make a lot of flooded extension modules without
cooperativeness (my musixuad is currently one of them!!), it is
not a fundamental improvement.
I feel some MusiXTeX kernel modification is needed. I will report
about this in near future.
## Therefore I do not hope to make present musixuad a standard.
Best regards,
Hiroaki MORIMOTO [EMAIL PROTECTED]
Tokyo, Japan
___
TeX-music mailing list
[EMAIL PROTECTED]
http://mailman.daimi.au.dk/mailman/listinfo/tex-music
