Christoph Reichenbach wrote:
> 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?
No, I haven't had time to do much yet (have 4 exams this week)
> I don't think we should distribute
> them with FreeSCI, though, unless we get explicit permission to do so.
Thats true.
> > 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 ;->
I guess I should have worded that better. After a PCM has been modified (which is
done realtime) by the patch information, it could possably sound entirly different.
A sine wave is very popular for that reason. Alot of the patches can be based on one
PCM, but sound entirly different.
> > 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 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.
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)
> > > 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.
Oh... you mean the games that have support for the Sound Blaster card with MT-32.
> > 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.
True, but it should be included in the FreeSCI main distrobution.
> > 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.
Yeah, I hadn't thought about that. They are big.
> > > 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?
I could have been thinking about the SBAWE32, which I know that is true. I'm not
really sure where I got that info, but I assumed it true because of what I knew
about other synths. They tend to use 128 patchs with a signifacantly less number of
accual waveforms. Maybe the MT-32 accually does have 128 waveforms in ROM, but I
seriously doubt it. I do know you can only add 32 partials, but 64 patchs.
> 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.
--
-Jay
