Age | Commit message (Collapse) | Author |
|
A new header file common/forbidden.h is included by scummsys.h and it
re-#defines numerous symbols like fopen(), fread(), system(), etc. with
garbage, in order to provoke compile errors in any code using them.
If a .cpp file really *must* use any of these (e.g. because it is a
backend file), then these redefinitions can be disabled by #defining
FORBIDDEN_SYMBOL_ALLOW_ALL as the first thing in the .cpp file. Whenever
this is done, an explanatory comment should be added.
Note that this system cannot catch all "bad" usages (notably the Lua
code in the sword25 engine), as it can only work if scummsys.h is
included.
svn-id: r53961
|
|
Often, a client has more than one available port. Pick the first one
that isn't already in use. For instance, on my computer client 17 is
the "Emu10k1 WaveTable", and it has four available ports. If, say,
aplaymidi is already playing on port 17:0, ScummVM will use port 17:1
instead. Otherwise the two programs will mess up each others
instruments and controller settings.
Of course, in reality I doubt that anyone will run two different MIDI
playing applications at once.
svn-id: r51380
|
|
This keeps ScummVM's own port from being included in the list of
available MIDI devices.
svn-id: r51378
|
|
Thanks to eriktorbjorn for some quick testing.
svn-id: r51366
|
|
svn-id: r51053
|
|
This is also an attempt to make the transition from the old settings to the
new ones a little less rough, by trying to put something sensible into the
first device, which is what's used by default. Currently it prefers 17:x
and 65:x since they're the old defaults, followed by 128:x since that's
probably TiMidity.
The old SCUMMVM_PORT environment variable still overrides any config
settings. I haven't made up my mind whether or not that's a good idea, but
at least it prints a warning message.
TODO: The old 'alsa_port' setting is not handled. It should probably be
used to set sensible defaults for the new settings, but I'm not sure where
this should be done.
TODO: The documentation will need to be updated, once everything is working
the way it should.
svn-id: r51019
|
|
We should probably open the sequencer the exact same way, both when
opening the driver and when asking it for available MIDI devices. Not
that I've been able to figure out the difference between "hw" and
"default" from the fine ALSA manual...
And I'm not sure we really need to try and keep compatibility with
ancient (pre-0.9.0?) ALSA any longer...
svn-id: r51014
|
|
ScummVM from crashing if, for instance, someone accidentally closes the driver
twice.
svn-id: r50870
|
|
svn-id: r50128
|
|
svn-id: r46315
|
|
svn-id: r43974
|
|
svn-id: r41037
|
|
- Updated all drivers to allow 264+2 byte sysEx messages
- Implemented sysEx processing for MT-32 for Kyra1 and HoF. MT-32 should now be working properly.
svn-id: r35180
|
|
used in more places. Help with this is highly welcome
svn-id: r34906
|
|
slight modification to the README changes. (I don't know how to interpret all
the output from aconnect, so I'm only documenting "the most important bit".)
svn-id: r33648
|
|
svn-id: r32698
|
|
svn-id: r32695
|
|
svn-id: r32693
|
|
- Added the MidiPlugin interface to the remaining MIDI drivers
- Added an initial MidiManager to handle the MIDI plugins (just static plugins by now)
svn-id: r32117
|
|
native MIDI drivers.
svn-id: r32097
|
|
svn-id: r31993
|
|
been updated.
svn-id: r28966
|
|
formerly knowns as Gaim) does; added new (incomplete) COPYRIGHT file; updated copyright dates in a few spots
svn-id: r27024
|
|
particular, we now always do so w/o framing the message (documented this with a Doxygen comment in the MidiDriver class)
svn-id: r25630
|
|
Waxworks (Simon engine). See http://www.borg.com/~jglatt/tech/midispec.htm for
reference.
* Added case for Aftertouch (Key Pressure).
* Changed Channel Pressure to flush the event immediatley. The message could
apply to notes while they are playing.
* Downgraded the error for unknown MIDI messages to a warning, and clarified it
slightly.
svn-id: r23949
|
|
svn-id: r21605
|
|
some SysEx client code.
Testing on Windows. Developers on other platforms, please verify integrity of music handling in your respective MidiDrivers.
svn-id: r20952
|
|
svn-id: r20951
|
|
svn-id: r20535
|
|
svn-id: r20088
|
|
svn-id: r19142
|
|
svn-id: r18604
|
|
svn-id: r18444
|
|
svn-id: r16398
|
|
modifications
svn-id: r14354
|
|
svn-id: r12533
|
|
svn-id: r12176
|
|
music driver
svn-id: r11583
|
|
bound to hit 1.0 any year now.
Of course, this is completely untested.
svn-id: r10288
|
|
svn-id: r10151
|
|
svn-id: r8814
|
|
svn-id: r8440
|
|
svn-id: r8219
|
|
svn-id: r8218
|
|
svn-id: r8210
|
|
svn-id: r7632
|
|
svn-id: r6726
|
|
svn-id: r6719
|
|
svn-id: r6272
|
|
svn-id: r5911
|