On Wed, Feb 06, 2002 at 11:17:49PM +1030, Alex Angas wrote:
> What I've been meaning with that is something I thought someone mentioned,
> somewhere... Pizza previously wrote a few lines regarding what the various
> levels could be but I can't find that e-mail presently. So am I correct by
> saying that these could be the various song iterator levels:
>
> Level | Example
> ---------------------------+---------------------------------------------
> SCI MIDI |
> General MIDI | mt32gm
> MIDI-to-file |
> Device | adlib(emu), mt32 (device itself)
> OS Subsystem | Win32 MCI
> Program | timidity
This isn't quite right:
> Level | Example
> ---------------------------+---------------------------------------------
> 0) SCI MIDI |
> 1) Device | adlib(emu), mt32 (device itself), gmidi(native)
> 2) Device translation | mt32gm
> 3) MIDI-to-file |
> 3) OS Subsystem | Win32 MCI, ALSA MIDI, OSS MIDI
> 3) Program | timidity
We will have a "native" General MIDI output driver in SCI1+ games.
However, we also need something to translate the MT-32 MIDI into
psuedo-GM output. This is technically a seperate layer.
Then that cooked MIDI stream has to get to a device somehow. However,
this device could be anything from the MCI stream driver to a file
writer to simple ossraw midi device.
> Then of course the question is how to interface between them all and perhaps
> also ensure that nonsense level combinations cannot occur (e.g. using adlib
> at the device level with the timidity program).
That's secondary -- the really hard part is to figure how to make the
interface generic enough to support the radically different demands of
realtime streaming (ossraw), filewriting, and the likes of the MCI
stream driver, which still needs events to bubble back up in realtime
but the song data has all technically been "played"
> When you say song iterators support looping, does that mean the sound
> servers won't have to worry about looping back themselves? That is, in
> effect the sound servers won't know about this, or?
They have to understand -- if for no other reason that there's a SET
LOOP soundserver command.. so once the song iterator has run out of
notes, we'd have to restart it. but internal song looping (eg the SET
LOOP POINT command) would be handled by the iterator -- but we'd still
have to tell the soundserver that a loop has occured so it can bubble
the loop event back up to the game loop.
(re-reads last paragraph)
(guh, that's a mess)
- 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"...
-- Attached file included as plaintext by Listar --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8YTy3ysXuytMhc5ERArKjAJkBsJI+5R6lO+gV8BiwxPrq9OFhHgCfUYyO
eck17azPGAMRDvZCJ/gSC2g=
=9tFn
-----END PGP SIGNATURE-----
