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
