Several list members have recently been engaged in a lively private
discussion about MIDI output from PMX. This all began when I sent this
small group a beta version of PMX with a rudimentary MIDI output capability.
I do not really want to make that version "public" at this time, because it
has some obvious shortcomings, and based both on my attempts to remedy those
problems as well as on these discussions, I'm certain that it will change
significantly in the near future. But I am taking the liberty of moving the
discussion onto the list. That will allow other interested parties to
contribute.
Stefan Evert wrote
>Something that occurred to me during the weekend: what if PMX didn't
>immediately produce a MIDI file, but rather some textual
>representation of the notes etc.?
To put this another way, what can Mr. PMX do for Mr. MIDI?
>This would very effectively modularise our design and allow us
>non-fortran-buffs to help Don by working on the post-processing step
>(which, obviously, doesn't require a knowledge of PMX's internal
>workings). It would even enable us to write the post-processor in
>something other than fortran, although it does probably make more
>sense to stick to fortran, and integrate it into the pmx binary in the
>end.
Not many people know FORTRAN any more, but I don't know any flavor of C. I
can see a two-track approach wherein PMX could internally produce a minimal
MIDI file, intended only for "proof-listening," while there could also be an
option for more elaborate post-processing along the lines Stefan suggests.
If we take this approach, I would be happy to leave all the coding in the
2nd mode to others, in which case there's no real advantage from FORTRAN.
>This is the design I've got in mind:
>
>(A) PMX parses input file, computes notes (start, pitch, length)
>separately for each voice, and stores notes together with additional
>information (ornaments, slurs, beams?, dynamic marks) in text file.
This is the really critical step. Key question are
1. In what order should the information be passed?
2. What information should be passed?
3. In what form should the information be passed?
Regarding the order, within PMX there are at least three different global
orderings already:
1. Input file order: N bars of voice 1a, [N bars of voice 1b], N bars of
voice 2, ...
2. First PMX internal order, where all the notes in all the voices in the
N-bar input block are arranged in order of start time;
3. Second PMX internal order, which corresponds to TeX output file order,
where the fundamental unit is a \notes grouping. I won't even try to
summarize this ordering in words :-).
Notice that none of these is ideal for generating a MIDI file, but in some
sense the input file order comes closest, because it keeps the largest
clumps of notes in the same voice together. There are even problems with
that, for example:
1. Because a second line of music in a staff can start and stop, sometimes
with very long intervals and one or more PMX input blocks between one stop
and the next start, these second lines should probably be included with the
main line in the same MIDI instrument (channel? track? not sure of the
terminology, but I'll use "instrument")
2. The MIDI file wants all the notes in instrument #1 for a whole movement
before starting instrument #2.
To further complicate matters, PMX does different levels of analysis and
recasting of information at each step as it (a) parses the input file, (b)
sorts into first PMX order, and (c) finally morphs it into the TeX order in
which it writes the output.
Regardless of the order in which information is passed from PMX to the MIDI
code generator, there are special problems with slurs, ties, chords, and
accidentals, about which I could write many paragraphs but will spare you.
I would be more than happy to entertain specific proposals for the form,
content, and phasing of data to be passed from PMX to the MIDI generator.
But to be totally honest, the more I think about it, the more it seems to me
that the best interface may simply be the PMX input file itself. A new
parser could be written to ignore all superfluous data and process the rest
exactly as needed for MIDI purposes. What then would PMX have contributed?
Well, mainly a descriptive language and a comprehensive syntax and timing
checker. The existing code for the latter (after tranlation to C?) could be
used entirely, in part, or not at all in the new MIDI-generator code. (Not
using it is surely a viable option; the user would just run PMX to do the
input checking, and could get a page image a fringe benefit).
If the approach were to use the pmx input file directly in this way, then I
would also be glad to include provisions in PMX for accepting and (if
desired) checking any special input related to MIDI file generation, but
then otherwise ignoring it.
--Don Simons
>(B) Post-processor reads text file. It's main part is a MIDI event
>scheduler which enables MIDI events to appear in a different order
>than the notes that trigger them, which may be necessary for trills
>and possibly for cresc./decresc. effects. This part of the program
>might also be used to identify ties and insert grace notes (I _think_
>it would be much easier that way than to hack everything in PMX's main
>loop).
>
>Optionally, another step might be inserted between (A) and (B) (i.e. a
>pre-processor for the post-processor :o) that tries to produce a more
>satisfactory rendering of the input. This is the part I'm _really_
>interested in. It should compute note lengths depending on slurs,
>ornaments, etc., and perhaps even add some dynamics. And, it would
>have to be configurable (did I hear anybody mention the word
>'style-sheets'?) for different musical styles and instruments (esp.
>note lengths, speed of trills, trill starts from upper or lower note?,
>etc.)
>
>Does this make any sense to you?
>Stefan.
