Hi,
On Tue, 26 Sep 2000, Jay wrote:
> > Sorry, I used an incorrect term there; I was referring to the PCM data
> > rather than the patches (which are part of the patch.001 resource present
> > in practically all SCI games).
> The PCM is Roland's property, but it is widely spread now. I doubt
> that Roland would give us any trouble if we didn't flaunt it too much.
Do you have a URL pointing to them? I don't think we should distribute
them with FreeSCI, though, unless we get explicit permission to do so.
> Extracting the PCM? Do you mean you want to emulate it from the ground
> up?!
I didn't say I /want/ to, but this would certainly result in the most
accurate sound output...
> The
> MT-32 is an LA synthisiser! That means 2 things:
>
> 1. Most LA only uses a small amount of PCM in the attack. It probably won't
> sound like what your used to hearing.
I'm used to hearing the MT-32, so if it's emulated correctly, it /should/
sound like what I'm used to hearing ;->
> 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.
> > > Working Timidity into FreeSCI is another story. I can get the patches, but
> > > Timidity is a stand alone MIDI player and FreeSCI will be generating a
> > > real-time MIDI streem.
> > IIRC, the timidity internals have been abstracted somewhat; I think I've
> > seen a libtimidity somewhere.
> Really?! Great! If anybody knows where that is, let the list know ASAP.
Can't find it... Either my memory is playing tricks on me, or I saw
something like a libtim.so for time zone support (or whatever). I've sent
a mail to the current TiMidity++ maintainer; maybe he knows something
about this.
> > > It seems like a multi-threading job.
> > The easiest way to handle this (on *NIX) would be fork()/execve() with
> > some pipes or socket pairs in between.
> Yeah, pthreads get messy sometimes. I aggree.
Note that this won't work on Win32/DOS. I think you could use sockets for
local communication in Win32 to run separate processes communicating with
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.
> > However, we'll have to accomodate
> > for actual PCM samples in SCI01 and later; this isn't a problem on Linux
> > with ALSA, but that's about the only target platform that will support
> > it.
> I think I lost you, please explain the above.
SCI01 and later (specifically QfG2- I'm not sure about KQ1) use PCM sound
effects. They can run only one of them concurrently, but they /can/ run
one while music is being played. This means that the digitized music
stream has to be mixed with the sound effect in real time. ALSA appears to
do this even when emulating OSS, but OSS (IIRC) doesn't support anything
like that. The situation may be similar on other platforms, so we have to
be able to mix sound effects into the output stream, which means that we'd
use timidity to generate the stream (but /not/ to output it), then pipe it
back to us, mix in the sound effect and output it. Again, Pipes don't work
on all systems, so using a timidity library with support for this (either
way) would be the best solution.
> > Unless there /is/ a libtimidity, we'd need to modify the actual timidity
> > for that
> Although it would suit our purposes to intergrate timidity directly into
> FreeSCI, I beleave whoever takes on this project should think of other
> projects as well. IOW if there is no libtimidity, there should be.
Good idea.
> Don't try to accually intergrate timidity and FreeSCI, make libtimidity,
> then work that into FreeSCI (or ask someone else on the list to do the
> accually intergration with FreeSCI).
Timidity (and, therefore, a timidity library) might be relatively big, so
I'm not sure if everybody would want to link against it anyway.
> > This would be possible (both technically and
> > legally, since timidity is lgpl'd).
> Are you sure you want to set that high of a goal?
It's possible to do it and I like the idea. Personally, I don't have the
time to work on it, though, so, unless somebody else wants to, it
probably isn't going to happen.
['normal' patches]
> I beleave we should
> include all of the patches in FreeSCI and use the game name to find out
> which ones to load. If you find that unacceptable, tell me.
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.
> > > We need a good
> > > hacker. Does anybody want to do that?
> > First, we need the PCMs. According to the Owner's manual, there are
> > supposed to be 128 of them.
> There aren't. There are only 32 I beleave. The patches are composed of
> realtime combinations and manipulations of the 32.
Are you sure you didn't mis-interpret something there? The MT-32 is able
to play 32 /partials/ simultaneously, and each instrument is a combination
of 1-4 of those partials (IIRC).
I couldn't find any indication that there are only 32 PCMs in the Owner's
Manual... where did you hear that?
> > Other than that, you should leave the process/thread separation to
> > Rickard's code, which is intended to make things much more modular than
> > the current sound infrastructure allows for.
> > Therefore, the only thing remaining to be done is a software
> > implementation of the MT-32, possibly using (parts of) timidity.
> You do want to emulate the whole thing, don't you? :-O
Full emulation is better than traditional PCM patch banks for normal sound
cards/Timidity is better than MT-32 -> GM translation is better than
nothing. I'll take whatever I get. Since I don't have time to work on
sound support in the near future, I don't have much of a choice ;-)
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 there is something in the MT-32 implementation that tells how
> to extract the internal PCMs in the Implimentation book somewhere. I
> have some work to do right now, but I'll look over it tomarrow. Until
> then, if anyone else want to look, I've included the MT-32 manual and
> Implimentation book from Lil' Chips.
> (Be sure you are working in a really high res. or scaleing viewer
> program).
> -- Binary/unsupported file stripped by Listar --
> -- Type: application/octet-stream
> -- File: mt-32_docs.tgz
For other readers who care:
It's available from http://www.lilchips.com/roland/synths/mt32/index.asp
(The owner's manual, the implementation chart, and some other stuff).
llap,
Christoph
