On Sun, Apr 08, 2001 at 01:12:21AM +0200, Christoph Reichenbach wrote:
> 1) Copy the code out of playmidi and pmidi (both are GPL'd) and adjust
> it to our purposes
> 2) fork() and execvp() playmidi, timidity, or pmidi
Both. It wouldn't be terribly difficult to create a midi_sequencer
driver, and once we have FreeSCI spitting out /dev/sequencer commands,
it becomes pretty easy to pipe them into TiMidity++ in *realtime*
It basically involves re-parsing the MIDI stream, but realistically,
that's already being done in several places. So one school of thought
is to make the freesci midi interface more complex (ie explicit noteon,
noteoff, change instrument commands) but I don't think this is
necessary.
> a) Orthogonal to our current sound subsystem approach
> b) No way to keep synchronized
> c) Fade-out only by means of global volume controls
a) not at all. ;)
b) in the case of piping the output into timidity++, we can maintain
"perfect" synchronization, and hell, even get /dev/sequencer support.
> (c) is particularly nasty. Using /dev/mixer or an equivalent may well
> backfire- especially for timidity- once we have sound effects to play.
We could just handle it via munging the note velocities, just like the
fading is handled now. It would be all of three additional lines of
code.
> If we use timidity, we can pipe the output back again and manually
> mix it and set its volume (Exult does something similar).
Now this is an interesting idea, but I think it should wait for "phase
two" -- ie, let's hold off on this until we hit games that use GMidi
natively. (Granted, we'll need to have a PCM subsystem in place by then
anyway)
- Pizza
--
Solomon Peachy pizzaATfucktheusers.org
I ain't broke, but I'm badly bent. ICQ# 1318344
Patience comes to those who wait.
...It's not "Beanbag Love", it's a "Transanimate Relationship"...
