The 'unix' identifier isn't defined when '-std' is passed to the compiler (tested with gcc and clang), so use '__unix__' which is well enough documented.
since they're int and not string settings.
- Fixed: FluidSynthMIDIDevice::FluidSettingInt() interpreted the return value from fluid_settings_setint() wrongly.
SVN r3993 (trunk)
but only supports three pan positions and not the full 127 MIDI pan positions.
- Added opl_core cvar to select emulator core. 0 is MAME and 1 is DOSBox.
- Added DOSBox's LGPL OPL core, distantly related to one adlibemu.c written by Ken Silverman
(not to be confused with the ancient MAME-derived and GPL-licensed core also found in DOSBox).
I believe this corresponds to their "compat" emulator, but I'm not sure.
SVN r3946 (trunk)
Full stereo panning for the MIDI player. (The raw OPL players are unaffected.) To get the
mono output back, you can set opl_stereo to false.
- Changed SoftSynthMIDIDevice::OpenStream() to allocate the same number of samples for stereo
and mono streams.
SVN r3929 (trunk)
sounds queued up while the Channel Group Target Unit is inactive will all play at the same time
once the unit is made active. To avoid this, it is now only deactivated when the gamestate is
GS_LEVEL. Otherwise, it just gets muted. Fixes http://forum.zdoom.org/viewtopic.php?f=2&t=33592 "Strife voices overlap"
SVN r3818 (trunk)
is supposed to be canceled by sysex events and meta events. This confused FMOD when the
resulting song used used running status right after these events.
SVN r3803 (trunk)
exit() can (and does) make the process hang. (It sure would be nice if
POSIX-land had a simple CreateProcess API, but I guess that would be too
easy, huh?)
SVN r3432 (trunk)
should ignore any tempo events in XMIDI songs that were left over from the original MIDI
files, since the converter didn't remove them.
SVN r3384 (trunk)
some of the stereoness of stereo sounds played in 3D. My testing was done only with stereo
speakers, however, and I did not realize that it was moving the perceived physical location
of the sound itself (because it sounded fine with my two speakers). So when 3D spread started
working with mono sounds as well in FMOD 4.28, sound positioning was completely broken for
everything when outputting to more than two speakers, because sounds were being spread
across a 180 degree arc.
Whoops!
Stereo sounds are now completely mono when not played by you, the listener.
SVN r3357 (trunk)
major change, so I'm making no provisions for using older FMOD DLLs when compiled with the
4.38 API. However, sound positioning is still broken like in 4.28, so you are recommended
to continue building with 4.26. Also, the Freeverb-based DSP unit is no longer present in
FMOD, so the underwater effect is currently unavailable when using 4.38 until I can figure
out how to make it work with the SFX Reverb unit instead. (And on that topic, the Freeverb
DSP was officially only for stereo outputs, so I really shouldn't have been using it in the
first place.)
- Since I would like to eventually figure out the sound positioning issues with the newer
FMODs, the following have been added:
* snd_drawoutput now labels its outputs with the speakers they represent.
* DCanvas::DrawTextA was added as an alias for DrawText, since the Windows headers #define
DrawText to a Unicode/non-Unicode variant.
* The loopsound console command was added to spawn an actor at the player's location and
have it loop a sound infinitely.
Hopefully I can figure it out. FMOD's 3D example works, so I assume the problem lies with
my code, though I don't really know where to begin looking for the problem.
SVN r3350 (trunk)
on the window_size, so for large numbers of output channels, it would not allocate enough
space for the spectrum data (which is definied by SPECTRUM_SIZE, not the window_size) and
write junk on the stack when drawing the spectrums, causing a crash.
SVN r3087 (trunk)
of signaling an event. I would have preferred to use GenerateConsoleCtrlEvent(), but since it
requires the caller be attached to the same console as the process it wants to kill, it's
pretty much worthless. We will continue to look for the presence of the event name in the
TiMidity++ binary despite no longer using it, because standard TiMidity++ builds do not write
to stdout in binary mode on Windows systems.
SVN r2980 (trunk)
