Hi,
> > 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
Agreed; it's mostly done (ossseq).
>, and once we have FreeSCI spitting out /dev/sequencer commands,
> it becomes pretty easy to pipe them into TiMidity++ in *realtime*
That would mean running timidity as a server (timidity -ir), or what are
you thinking of?
I don't know whether Timidity supports single MIDI events in this mode...
[...]
> b) in the case of piping the output into timidity++, we can maintain
> "perfect" synchronization, and hell, even get /dev/sequencer support.
I was thinking along the lines of actually piping the data into Timidity
there. This is totally different from what we're doing now.
> > (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.
Again, that would work for a /dev/sequencer recipient and maybe for a
MIDI server, but not for a pipe destination (we tried that...)
llap,
Christoph
