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*** readmidi.c.orig Fri Dec 18 21:28:34 2009
--- readmidi.c Sat Feb 20 11:11:56 2010
***************
*** 3132,3140 ****
return 0;
}
if(len >= 8 &&
val[0] == 0x43 &&
! val[1] == 0x10 &&
val[2] == 0x4C)
{
int addr = (val[3] << 16) | (val[4] << 8) | val[5];
--- 3132,3152 ----
return 0;
}
+ /* val[1] can have values other than 0x10 for the XG ON event, which
+ * work on real XG hardware. I have several midi that use 0x1f instead
+ * of 0x10. playmidi.h lists 0x10 - 0x13 as MU50/80/90/100. I don't
+ * know what real world Device Number 0x1f would correspond to, but the
+ * XG spec says the entire 0x1n range is valid, and 0x1f works on real
+ * hardware, so I have modified the check below to accept the entire
+ * 0x1n range.
+ *
+ * I think there are/were some hacks somewhere in playmidi.c (?) to work
+ * around non- 0x10 values, but this fixes the root of the problem, which
+ * allows the server mode to handle XG initialization properly as well.
+ */
if(len >= 8 &&
val[0] == 0x43 &&
! (val[1] >= 0x10 && val[1] <= 0x1f) &&
val[2] == 0x4C)
{
int addr = (val[3] << 16) | (val[4] << 8) | val[5];
*** mix.c.orig Mon Jan 23 03:07:44 2006
--- mix.c Sun Sep 6 18:49:40 2009
***************
*** 1628,1634 ****
{
int stage, ch, eg_stage;
int32 offset, val;
! FLOAT_T rate;
Voice *vp = &voice[v];
stage = vp->envelope_stage++;
--- 1628,1634 ----
{
int stage, ch, eg_stage;
int32 offset, val;
! FLOAT_T rate, temp_rate;
Voice *vp = &voice[v];
stage = vp->envelope_stage++;
***************
*** 1641,1646 ****
--- 1641,1660 ----
/* there is some difference between GUS patch and Soundfont at
envelope. */
eg_stage = get_eg_stage(v, stage);
+ /* HACK -- force ramps to occur over 20 msec windows to avoid pops */
+ /* Do not apply to attack envelope */
+ if (eg_stage > EG_ATTACK)
+ {
+ temp_rate = control_ratio * (labs(vp->envelope_volume - offset) /
+ (play_mode->rate * 0.02));
+ if (temp_rate < 1)
+ temp_rate = 1;
+ if (rate < 0)
+ temp_rate = -temp_rate;
+ if (fabs(temp_rate) < fabs(rate))
+ rate = temp_rate;
+ }
+
/* envelope generator (see also playmidi.[ch]) */
if (ISDRUMCHANNEL(ch))
val = (channel[ch].drums[vp->note] != NULL)
***************
*** 1708,1713 ****
--- 1722,1742 ----
} else if (rate < 1) {rate = 1;} /* slowest attack */
}
+ /* HACK -- force ramps to occur over 20 msec windows to avoid pops */
+ /* Do not apply to attack envelope */
+ /* Must check again in case the above conditions shortened it */
+ if (eg_stage > EG_ATTACK)
+ {
+ temp_rate = control_ratio * (labs(vp->envelope_volume - offset) /
+ (play_mode->rate * 0.02));
+ if (temp_rate < 1)
+ temp_rate = 1;
+ if (rate < 0)
+ temp_rate = -temp_rate;
+ if (fabs(temp_rate) < fabs(rate))
+ rate = temp_rate;
+ }
+
vp->envelope_increment = (int32)rate;
vp->envelope_target = offset;
***************
*** 1845,1853 ****
#endif
{
int32 max_win, delta;
!
! /* reduce popping -- ramp the amp over a <= 0.5 msec window */
! max_win = play_mode->rate * 0.0005;
delta = FROM_FINAL_VOLUME(vp->left_mix) - vp->old_left_mix;
if (labs(delta) > max_win) {
vp->left_mix_inc = delta / max_win;
--- 1874,1882 ----
#endif
{
int32 max_win, delta;
!
! /* reduce popping -- ramp the amp over a 20 msec window */
! max_win = (play_mode->rate * 0.02) / control_ratio;
delta = FROM_FINAL_VOLUME(vp->left_mix) - vp->old_left_mix;
if (labs(delta) > max_win) {
vp->left_mix_inc = delta / max_win;
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Timidity-talk mailing list
Timidity-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/timidity-talk
