> > > I'm sure you don't have sysex
> > > uploading happening yet,
>
> Trust me, we do. At least on alsaraw, unixraw, and ossseq; the interfaces
> are abstracted sufficiently correctly that it _should_ be happening on
> win32mci as well, at least as far as I can tell. Does it at least print
> something during startup saying that it is uploading patches? (It should
> be, if mt32 mode is enabled, i.e. by passing the "-Mmt32" command line
> option or setting the appropriate value in the config file.)
"-Mmt32?" I used "-mt32" and the console did list a pile of midi patches it
was "loading" or preparing so I'll take it that was a type-o. No noticable
message on the MT-32 regarding patch uploading.
>
> > > but I can't imagine there was much in the way of
> > > sysex on LSL3.
>
> Actually, LSL3 re-programs pretty much everything. Except for KQ4 and
> LSL2, all games appear to use a large number of instruments defined
> manually (well, with the partial exception of PQ2 which uses a relatively
> small patch set).
>
Yes sorry, that is right, LSL3 does use a lot of sysex, I remember now.
> > > it's more than just the lack of sysex.. I think it might be
> playing the
> > > same instrument for all tracks. I don't know how to operate the MT32
> > > manually (i.e. the controls) to find out. But it sounds that way.
> >
> > Thanks for articulating this so well, I had difficulty explaining it to
> > Chris and Solomon.
>
> I guess we should log output from the win32mci driver and compare it to
> output from other drivers.
> Then again, there may be timing issues; does the MT-32 in question signal
> "Exec. buffer overflow"?
Nope, if it does, it doesn't stay on the LCD long enough to read it. I know
that's an issue with sierra's SCI on fast machines but I haven't had that
problem. Maybe FreeSCI is TOO FAST that I don't even get to see the overflow
message. *shrug*
- Taylor
