[Scummvm-devel] mt-32 emu by default?

athrxx athrxx at users.sourceforge.net
Wed Sep 15 18:01:30 CEST 2010


A quick approach to solve the issue with those default midi devices  could
be to drop the "<default>" options from the midi and mt-32 launcher tabs and
replace them with "<no gm music>" / "<no mt-32 music>". Currently
detectMidiDevice() will always try to return some gm or mt-32 device if the
engine requests this via MDT_PREFER_xx flags and the launcher settings for
those devices are set to <default>. Instead, we could skip gm and/or mt-32
detection unless the user has indicated (by expressly selecting devices in
the main options tabs) that he has such devices which he also wants to use.

With this approach users without (good) midi devices would get Adlib sound
without having to change any settings and PC users would have to select
their midi devices once, but would not be required to reconfigure every
single target (which would be the case if you just drop the MDT_PREFER_xx
flags from the engines).




Florian



-----Ursprüngliche Nachricht-----
Von: Max Horn [mailto:max at quendi.de] 
Gesendet: Mittwoch, 15. September 2010 15:41
An: yotam barnoy
Cc: ScummVM devel; Johannes Schickel
Betreff: Re: [Scummvm-devel] mt-32 emu by default?


Am 15.09.2010 um 15:16 schrieb yotam barnoy:

> I agree, and I think I think I have some of these problems on the PSP
> too, with the wrong sound device being selected automatically.
> 
> I think that we should have some other mechanism for recommending the
> best sound choice for the game. Perhaps the launcher should have a
> field called 'Recommended Device:' in the per-game sound tab, just to
> give a hint to the user.

Actually, going beyond that, I think we should consider the following (but
as Johannes already said, of course after branching 1.2.0):

First off, each engine should be able to specify (potentially for every game
separately) a preference order on supported music formats. 

On the other hand, the launcher resp. the backend should also be enabled
(somehow, not yet clear to me how) to affect this. E.g. by default, we would
always move down MT-32 below other drivers / formats. 

The idea here is that one the one hand, an engine should be allowed to
correctly reflect which sound options are "best", w/o having to worry
whether the user will be able to make use of that; OTOH, the backend /
launcher should be able to adjust this to reality. In the future, this then
could also be improved to take into account availability of certain music
devices or even drivers: By adding a MusicDriver API which allows querying
whether a given device is available. The MT-32 emu then would simply return
"false" if it can't find the required ROMs. Or the seq driver would return
false if no MIDI device was set up. Etc.

Lastly, we *could* allow the user to also affect this ordering (by default,
on the global level; it should be necessary on a per-game or per-engine
level) to tweak this. e.g. if users happen to have an MT-32 attached which
is reachable via /dev/seq, then they should be able to move "MT-32 via this
particular /dev/seq device" to the top.

Anyway, our Music driver design got a bit better already (and a bit worse,
due to hopefully fixable regression), yet we still have a lot of ground to
cover until it is really *good* not to mention great... :)


Bye,
Max
----------------------------------------------------------------------------
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Scummvm-devel mailing list
Scummvm-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scummvm-devel





More information about the Scummvm-devel mailing list