Hi,
On Sat, 15 Dec 2001, Chris Kennedy wrote: [extended MIDI mode] > I don't really know specifically. However, after some more work with > everything....it looks as if it was actually related to driver & synth > setup. One culprit was an option on my end. I have a Turtle Beach Santa Cruz > soundcard. I have control over midi notes played back by hardware and > software. I disabled the hardware playback completely, and the chords or > long notes in songs (in SQ3 and Camelot) would hold. The percussion oddness > in SQ3 is most likely due to instrument mapping from mt32 to general midi. That's possible. [...] > win win32p) SDL synth sounds basically just like win32p. What is the > difference between win32p and win32e? IIRC win32p runs in a separate thread, whereas win32e uses timed win32 messages, but I haven't even run the win32 port yet, so I'm not qualified to comment on these ;-) > As a side note regarding base, extended, and general midi - (a little > Sierra trivia) - Midi COULD be controlled in the much later versions of SCI > (As in the Windows based ones) by a line contained in resource.win: > > synthtype=basesynth > # would be the line to use for base instruments only > synthtype=highsynth > # I believe would be General Midi 1-16. > > Sierra would actually have you change it to basesynth if you were having > troubles with midi notes hanging during playback. While they thought this > was a fine and dandy solution, all it did was kill the top 6 channels of > your midi songs. Therefore, you would actually LOSE instruments in the > songs. A cheap way to kill off notes that are occupying too many voices... hmm... > I know this is a looonnnng way off (most likely), but hopefully > freesci can overcome sierra's problem without dropping instruments. :) Please consider that hardware MIDI sequencers have a hardware limitation of how many voices they can play simultaneously. Our approaches at trying to tune our MIDI output to accomodate for this have been fruitless (they were aimed at sending a note-off for an old voice if a note-on for a new tone was received and the channel limit was exceeded, but it didn't change anything). > P.S. I have ddraw listed for a graphics driver. Unless I overlooked it in > the readme file, I am unsure how to switch over to ddraw from SDL for the > graphics driver. Graphics drivers can be specified with the '-g' option, but IIRC the ddraw driver isn't working yet (please correct me if I'm wrong...). > For all I know, switching to this will reduce the tax on > graphics processing and therefore allow the win32e sound server to play up > to speed. That's a bit optimistic; I'm not sure if the impact will be that great (although I must admit that SDL is considerably slower than plain xlib on UNIX, particularly when displaying on remote X11 servers). IIRC the timing issues are due to Win32 not keeping its timing promises wrt delayed messages in general (again, please correct me if I'm wrong- this is the impression I got from the previous threads on this topic); we've discussed a proposal to use the Win32 MIDI API (DirectMIDI or something like that) instead by splitting the code that keeps track of where we are in the song from the code that plays it. This would create slight problems with synchronity of what you see and what you hear, but it would help a lot with implementations on other systems with no or restricted multi-tasking (such as classic MacOS) as well. > (Which would basically only leave mt32 instrument mapping as the > only problem) There's actually a way of tuning the instrument mapping, but it's not particularly easy to use yet. Since this is a feature, it would make sense to look at this again before the 0.4.x beta release series begins. llap, Christoph
