Eric Peterson wrote
>[Don wrote]
>> 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.
>
>I think, given the number of free and shareware MIDI file editors
available,
>that PMX should stick to the "minimal MIDI file" approach. As long as all
>the notes are right, adjusting the volume, etc., should be left to a
>dedicated MIDI file editor. The sticky parts -- of getting the notes right
>-- that I see are musical shorthand such as (1) grace notes, trills,
>arpeggios, etc., (2) repeats and voltas, and (3) transposition.
Different people will draw different boundaries for a "minimal MIDI file",
for which kinds of notes have to be right, and for what to leave to "etc".
For example, I have no current intention to include ornaments in the
baseline capability. If someone wants ornaments in the meanwhile, the
options I see are (a) someone else get into the guts of PMX, in FORTRAN; (b)
someone independently creates a more elaborate midi file generator that uses
the pmx input file, (c) I create an output file at some intermediate stage
(as I've already discussed a little), to be used as partially digested and
fully formatted input for someone else's more elaborate mid file generator,
or (d) operate on the ornament-less midi file with an advanced midi file
editor.
>Items (1) are all "local" modifications, and are therefore should be
>relatively straightforward to add (says the spectator),
Maybe. But as I said, I don't plan to do this, at least not for ornaments.
So doing it locally means option (a). Someone else would have to learn some
things, probably a lot of things, about the internals of both basic PMX and
the built-in MIDI file generator. I'd love it if anyone wanted to do that,
and I'd be willing to spend some effort myself to help them up to speed, but
I'm not holding my breath that anyone is willing to do that. Ergo options
(b)-(d). With respect to option (c) I've identified a likely spot within
PMX and even started a detailed description of how data are organized there,
which I'd be glad to send anyone who's interested.
>while items (2) and
>(3) are "global." I imagine that (2) could get to be very messy. (State
the
>obvious and run.)
I'm running right along side.
>Finally (3) has several difficulties: I can imagine that a
>composer might want to enter notes at the actual pitch and rely on PMX to
>produce the "correct" printed score, while a copyist might rather enter
the
>notes from a printed score and rely on PMX to produce the correct actual
>pitch. These must both be accomodated.
I haven't put much thought into special midi-related transposition issues.
Sure looks like something for the "etc." category. As to assigning
instrument-specific transpositions in the *printed* score, that might not be
too difficult to program.
Are you suggesting that a composer might want to use pmx? Composition is
definitely not among the uses I have in mind for PMX. It's mainly a
formatter/typesetter. The internal MIDI file generator is mainly for
proof-listening. As such it ought to be able to process any otherwise
legitimate PMX file without choking. My near-term objective is to get it to
that point. BTW, I'm getting close :-)
--Don Simons
