[timidity-talk] readmidi.c XG SYSTEM ON SYSEX bugfix attached, mix.c anti-popping fix attached

[Eric W. <ew...@bi...>]

On Sat, 6 Feb 2010, / ririka_sos / wrote:

> >>> XG reset event problem in server mode.  As it is now, I'm only able to
> >>> build the standard player with cygwin+mingw32.
>
> If you're talking about building twsyng binary,
> MinGW(5.1.4/5.1.2) + Msys(1.0.11-2004.04.30-1) may help you.
> # tested with TiMidityCVS080327, bit older version.

> ./configure --enable-winsyn --enable-winsyng

I installed MinGW + MSYS, ran configure with the appropriate options,
and TWSYNTH compiled and ran fine.  Big thanks!

> If you set "--enable-w32gui" in addition to "--enable-winsyn --enable-winsyng",
> configure passes, but built in failure.

I got the Windows MIDI driver to build by using --enable-windrv instead of
--enable-winsyng.  It, too, needs to configure and compile all by itself,
you evidently can't build TWSYNTH and the driver at the same time.  Driver
works great.  TWSYNTH is nice for debugging, though, since I don't have to
reboot every time I recompile :)

Looks like my problems were all coming from trying to use cygwin to
cross-compile in MinGW mode (-mno-cygwin flag).  A pure MingGW build
environment fixed everything.

-----

I have attached a diff (readmidi_xg_sysex.diff) to fix a bug with
interpreting XG SYSTEM ON SYSEX events.

playmidi.c: Allow Device Numbers other than 0x10 for XG SYSTEM ON SYSEX events

See comments in diff for longer explanation.  All my XG midi files play
fine in server mode now.

-----

I am also resubmitting an anti-popping patch I submitted a few months ago
(mix_fix_amps.diff) after a discussion on this list.

mix.c: Fix existing anti-popping minimum volume ramps for expression,
       volume, pans, etc..  Extend anti-popping minimum volume ramps to
       envelope amp changes.


In adding the envelope volume ramps, I found that I had mis-implemented
the original "reduce popping" code in compute_mix_smoothing() many years
ago.  The previous 0.5 msec comment was wrong, since the code was
effectively working over 20 msec and I only *thought* it was 0.5 msec from
my incorrectly written code.  Looking at WAV output in a sample editor
confirms this.  I have changed the calculation to correctly take the
control_ratio into account, and changed the comment to reflect the actual
minimum ramp time.

I was originally hesitant to add anti-popping minimum volume ramp times to
envelope calculations, since they would add very minor delays to extremely
fast envelope rates.  However, saner minds convinced me that this was a
good idea for the following reasons:

1) 20 msec is very short to begin with
2) It has been used for expression, volume, and pan changes for many years
   with no noticible problems.
3) Most GUS instruments have rates longer than this anyways, so they
   would not be affected at all.
4) I think the GUS PAT loader checks for missing envelope rates and sets
   them to defaults that are longer than 20 msec.
5) This effectively adds some reasonable defaults to soundfonts if the
   envelope rates are missing (which is not uncommon).
6) Other software synthesizers and real hardware do not have popping
   problems with soundfonts that are missing envelopes.  They must be
   adding their own volume ramps to envelope changes to avoid these pops.
   Therefore TiMidity++ should too, so that it can have soundfont support
   that is more compatible with other players/hardware.
7) Enforcing minimum envelope times should avoid other unforseen popping
   problems in the future.

I fully support adding minimum volume ramp times to envelopes now.

-Eric