Hi,
> > > 2. LA is complex, I would judge imposible to emulate without more information
> > > on Roland's hardware.
> >
> > Have a look at http://freesci.cx/mt32.txt, which Rickard dug up a while
> > ago. There's a lot of interesting stuff covered in there.
> I can't get there right now for some reason ??? is the site up?
It should be up as long as telefragged.com is up (and as long as you can
connect to the CX-NIC). Try http://freesci.linuxgames.com/mt32.txt. Same
IP, same path, different nameserver hierarchy.
[...]
> > each other, but it'd be ugly. The only way to "multitask" on DOS is using
> > an Int 8 handler (or the sofware interrupt called by it).
> > Anyway, this should plug into Rickard's sound infrastructure in some way,
> > so the multitasking and IPC can be left to OS-dependant abstraction
> > layers.
> That might disappoint some people. Is there a way to tie it into the
> main loop somewhere? (I'm not going to be the one to intergrate it, so
> I'm just passing ideas)
Using the main loop to process sound is not a good idea. Some
atomic operations (especially graphical operations) may take much too long
for this to work sensibly when doing real-time mixing. We have a separate
sound server process now (on UNIX), and we can have something similar
(threaded) on Win32 and (Int 8 handler) on DOS. Abstracting this is part
of what needs to be done for the sound system, and I'm pretty sure that
it's possible to find a sensible solution for this /there/.
[Sound effects]
> Oh... you mean the games that have support for the Sound Blaster card
> with MT-32.
Actually, all games that support digitalized sound effects, although those
two sets of games may be identical.
> > Timidity (and, therefore, a timidity library) might be relatively big, so
> > I'm not sure if everybody would want to link against it anyway.
> True, but it should be included in the FreeSCI main distrobution.
That depends. If it can be split into a decent separate library with
support for sound effects and everything, then, by all means, it should
become a separate library. We don't ship with glib preinstalled either.
I don't think this will be a problem for the source distribution; binary
distributions (we only do Win32 and DOS there) might ship with libtimidity
compiled in. *NIX distributions are for the downstream maintainers to
worry about.
> > Including them is unacceptable, as they're likely a few MB in size. Also,
> > I'm not sure if we are allowed to distribute them legally. Adding support
> > for loading them into a libtimidity or wavetable sound cards (using libawe
> > and similar stuff) makes sense, though.
> Yeah, I hadn't thought about that. They are big.
We should link to them once/if we support them, though, or even host them
if possible.
> > Anyway, are you interested in working on any of this (and do you think
> > you'll have the time and skill for that)? Rickard's currently busy with
> > his studies, so I guess he'd appreciate any help.
> I beleave I could hack timidity, but I've never looked at its code.
> Time is limited to the weekends for me, but I think I could do it. It
> will be an intresting experence.
Great! :-)
The work required to support TiMidity would be split in two parts, then:
Libtimidity, and a libtimidity interface in Rickard's sound code. The
sound code isn't here yet, though (as I said, Rickard's currently busy
studying, and may be so for another month or more), so if you finish with
libtimidity before that, you'll have to ask him for his view on this and
how it should be implemented in his infrastructure.
llap,
Christoph
