Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Updated TiMidity++ 2.13.2 test build

0 views
Skip to first unread message

Alex Taylor

unread,
Aug 21, 2009, 7:13:02 AM8/21/09
to
My TiMidity++ 2.13.2 test build has been updated again.

Files available at:
http://users.socis.ca/~ataylo00/programming/ports/#timidity
(Binary: timidity-2.13.2_test.zip)
(Source: timidity_source-2.13.2_test.zip)


Notable changes:
- Fixed buffer overrun causing crash when parsing MIDI files with very
long comment lines.
- There should no longer be a delay and "Output Flush timed out" error
message between playing files.
- Selection cursor in the playlist now follows active file.
- Configure logic improved considerably (only affects source code).
Also now building with -Zomf flag.


Still-outstanding bugs:
- The GUI treats any file not containing ".MID" in the filename as not
supported by TiMidity, and tries to play it using MMOS/2 instead. I
need to make the detection more intelligent.
- The button controls sometimes lose track of the current state, which
could cause them to become nonfunctional. (This tends to show up if
you do things like clicking 'Restart' while a song is paused.)


The best way to install is to have an existing TiMidity installation
(e.g. from my WPI files of v2.10.4) and then simply copy timidity.exe
over the old one (back it up first, of course). If you have a program object,
either add the '-io' switch to the parameters if you want to
use the GUI, or rename the executable to 'timidpm.exe'.

--
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.

Gregg Young

unread,
Aug 30, 2009, 6:57:07 PM8/30/09
to
Alex

Thanks for the update. I tried it on my duel core and it did play well
with 2 processors (odd pm hangs). On one it was better. I always had to
play a nonmidi sound file or restart the pm interface after playing a
midi or the 2nd file failed. I tried building it. interface/makefile
doesn't get the .s added to the SUFFIXES list. Your source tree isn't
complete. muldiv.s was in the root instead of interface tim_pm.ico was
in the root instead of os2-icons and the following were missing all
together:

timidity.rc(16) RC: error - file not found: os2_icons\open.ico.
.
timidity.rc(17) RC: error - file not found: os2_icons\play.ico.
.
timidity.rc(18) RC: error - file not found: os2_icons\pause.ico.
.
timidity.rc(19) RC: error - file not found: os2_icons\stop.ico.
.
timidity.rc(20) RC: error - file not found: os2_icons\prev.ico.
.
timidity.rc(21) RC: error - file not found: os2_icons\next.ico.
.
timidity.rc(23) RC: error - file not found: os2_icons\restart.ico
....RC: 7 errors detected

Gregg

Alex Taylor

unread,
Aug 31, 2009, 10:17:01 AM8/31/09
to
On Sun, 30 Aug 2009 22:57:07 UTC, Gregg Young <ygk.n...@qwest.net> wrote:


> Thanks for the update. I tried it on my duel core and it did play well
> with 2 processors (odd pm hangs). On one it was better. I always had to
> play a nonmidi sound file or restart the pm interface after playing a
> midi or the 2nd file failed. I tried building it. interface/makefile
> doesn't get the .s added to the SUFFIXES list. Your source tree isn't
> complete. muldiv.s was in the root instead of interface tim_pm.ico was
> in the root instead of os2-icons and the following were missing all
> together:
>
> timidity.rc(16) RC: error - file not found: os2_icons\open.ico.
> .
> timidity.rc(17) RC: error - file not found: os2_icons\play.ico.
> .
> timidity.rc(18) RC: error - file not found: os2_icons\pause.ico.
> .
> timidity.rc(19) RC: error - file not found: os2_icons\stop.ico.
> .
> timidity.rc(20) RC: error - file not found: os2_icons\prev.ico.
> .
> timidity.rc(21) RC: error - file not found: os2_icons\next.ico.
> .
> timidity.rc(23) RC: error - file not found: os2_icons\restart.ico
> ....RC: 7 errors detected

OK. I've updated the source zip; try downloading it again now.

Not sure what to do about your other problems. Does they happen only
with the PM interface, or also with ncurses/dumb?

Gregg Young

unread,
Sep 1, 2009, 7:38:43 PM9/1/09
to

>
> OK. I've updated the source zip; try downloading it again now.
>
> Not sure what to do about your other problems. Does they happen only
> with the PM interface, or also with ncurses/dumb?
>

I got the new source but now I have a new error which I can't figure out:
rm -f libinterface.a
u:/usr/bin/emxomfar cru libinterface.a dumb_c.o wrdt_dumb.o wrdt_tty.o
ncurs_c.o
pm_c.o muldiv.o
emxomfar: libinterface.a(dumb_c.o): Record too long
make.exe[3]: *** [libinterface.a] Error 2
make.exe[3]: Leaving directory `U:/TiMidity++-2.13.2/interface'
make.exe[2]: *** [all-recursive] Error 1
make.exe[2]: Leaving directory `U:/TiMidity++-2.13.2/interface'
make.exe[1]: *** [all-recursive] Error 1
make.exe[1]: Leaving directory `U:/TiMidity++-2.13.2'
make: *** [all] Error 2

Any ideas what Record too long is referring to?

As for the other issues I only saw them in the pm version but I really
didn't do much testing with the other interfaces. If I ever get it to
build I will see if I can address some of the issues.

Thanks

Gregg

Dave Yeo

unread,
Sep 1, 2009, 7:50:21 PM9/1/09
to
On 09/01/09 04:38 pm, Gregg Young wrote:
> Any ideas what Record too long is referring to?

Try emxomfar -p256 cru.
Are you using EMX or klibc? If EMX then you need CFLAGS=-Zomf as well as
LDFLAGS. If klibc you should be using ar, not emxomfar unless CFLAGS
include -Zomf in which case the static lib suffix should be .lib not .a
Dave

Gregg Young

unread,
Sep 1, 2009, 8:15:42 PM9/1/09
to

Dave

I am using EMX; -Zomf is set. I tried -p256 with the same result. Thanks
for the quick response.

Gregg

Dave Yeo

unread,
Sep 2, 2009, 1:41:46 AM9/2/09
to

Well if you are using EMX you are going to have to hack the makefiles to
use .lib as the suffix for static libs.
I did successfully build an earlier version of Alex's Timidity sources
with klibc. Much easier as klibc can dynamically convert aout to omf.
Just need to use the toolkit for the multimedia libs.
Dave

Alex Taylor

unread,
Sep 2, 2009, 9:40:01 AM9/2/09
to
On Wed, 2 Sep 2009 00:15:42 UTC, Gregg Young <ygk.n...@qwest.net> wrote:

> I am using EMX; -Zomf is set. I tried -p256 with the same result. Thanks
> for the quick response.

Just a quick check, you are using reconf.cmd instead of running configure
directly?

Alex Taylor

unread,
Sep 2, 2009, 9:43:01 AM9/2/09
to
On Tue, 1 Sep 2009 23:38:43 UTC, Gregg Young <ygk.n...@qwest.net> wrote:

> I got the new source but now I have a new error which I can't figure out:
> rm -f libinterface.a
> u:/usr/bin/emxomfar cru libinterface.a dumb_c.o wrdt_dumb.o wrdt_tty.o
> ncurs_c.o
> pm_c.o muldiv.o
> emxomfar: libinterface.a(dumb_c.o): Record too long
> make.exe[3]: *** [libinterface.a] Error 2
> make.exe[3]: Leaving directory `U:/TiMidity++-2.13.2/interface'
> make.exe[2]: *** [all-recursive] Error 1
> make.exe[2]: Leaving directory `U:/TiMidity++-2.13.2/interface'
> make.exe[1]: *** [all-recursive] Error 1
> make.exe[1]: Leaving directory `U:/TiMidity++-2.13.2'
> make: *** [all] Error 2
>
> Any ideas what Record too long is referring to?

No. I've certainly never seen that.

What version of GCC do you have? I'm building with the EMX-bundled
version (2.8.1), and not PGCC or anything like that...


> As for the other issues I only saw them in the pm version but I really
> didn't do much testing with the other interfaces. If I ever get it to
> build I will see if I can address some of the issues.

Well, if it only shows up in the PM interface, that's good and bad.
Good, because it means the bug isn't likely in the DART module, which
I don't understand. Bad, because it may be in the parts of the PM
module which call the MMOS/2 APIs directly, and which I also don't
(much) understand.

Gregg Young

unread,
Sep 2, 2009, 11:09:32 PM9/2/09
to
Alex Taylor wrote:
> On Wed, 2 Sep 2009 00:15:42 UTC, Gregg Young <ygk.n...@qwest.net> wrote:
>
>> I am using EMX; -Zomf is set. I tried -p256 with the same result. Thanks
>> for the quick response.
>
> Just a quick check, you are using reconf.cmd instead of running configure
> directly?
>

Yes

Gregg Young

unread,
Sep 2, 2009, 11:16:31 PM9/2/09
to

Dave

Where do I get the toolkit I am using gcc 3.3.5 Paul's build
environment. I will try changing to .lib but I am actually using Alex's
make files which apparently work for him. Thanks

Gregg

Gregg Young

unread,
Sep 2, 2009, 11:19:17 PM9/2/09
to
Alex Taylor wrote:
> On Tue, 1 Sep 2009 23:38:43 UTC, Gregg Young <ygk.n...@qwest.net> wrote:
>
>> I got the new source but now I have a new error which I can't figure out:
>> rm -f libinterface.a
>> u:/usr/bin/emxomfar cru libinterface.a dumb_c.o wrdt_dumb.o wrdt_tty.o
>> ncurs_c.o
>> pm_c.o muldiv.o
>> emxomfar: libinterface.a(dumb_c.o): Record too long
>> make.exe[3]: *** [libinterface.a] Error 2
>> make.exe[3]: Leaving directory `U:/TiMidity++-2.13.2/interface'
>> make.exe[2]: *** [all-recursive] Error 1
>> make.exe[2]: Leaving directory `U:/TiMidity++-2.13.2/interface'
>> make.exe[1]: *** [all-recursive] Error 1
>> make.exe[1]: Leaving directory `U:/TiMidity++-2.13.2'
>> make: *** [all] Error 2
>>
>> Any ideas what Record too long is referring to?
>
> No. I've certainly never seen that.
>
> What version of GCC do you have? I'm building with the EMX-bundled
> version (2.8.1), and not PGCC or anything like that...

I am using Paul Smedley's 3.3.5 build environment.


>
>
>> As for the other issues I only saw them in the pm version but I really
>> didn't do much testing with the other interfaces. If I ever get it to
>> build I will see if I can address some of the issues.
>
> Well, if it only shows up in the PM interface, that's good and bad.
> Good, because it means the bug isn't likely in the DART module, which
> I don't understand. Bad, because it may be in the parts of the PM
> module which call the MMOS/2 APIs directly, and which I also don't
> (much) understand.
>

I need to do more testing before saying it is only the PM interface. Thanks

Gregg

Dave Yeo

unread,
Sep 3, 2009, 12:57:46 AM9/3/09
to

I just tried to build the latest source. At first I didn't run reconf. I
had to battle with ncurses-5.5-OS2 as the headers were in
include/ncurses and the headers didn't have the right reference.
Eventually the build died with unresolved symbols while linking
timidity.exe.
I then ran reconf.cmd and tried building again and got the same error as
Greg.
Looking at the build log the first run with your configuration used
-Zomf in the CFLAGS and .obj as the suffix for the object files.
Second run after running reconf.cmd (and editing config.h) it did not
use -Zomf and used ar to build the static libs until libinterface.a
where it used emxomfar which couldn't handle the aout object files.
Dave

Dave Yeo

unread,
Sep 3, 2009, 1:06:45 AM9/3/09
to
On 09/02/09 08:16 pm, Gregg Young wrote:
>
> Where do I get the toolkit I am using gcc 3.3.5 Paul's build
> environment. I will try changing to .lib but I am actually using Alex's
> make files which apparently work for him. Thanks

They are located at
http://hobbes.nmsu.edu/h-browse.php?dir=/pub/os2/dev/emx/v0.9d. Start
with INSTALL.DOC and remember you can set everything in a cmd file
instead of config.sys.
I built an earlier test build with GCC 3.3.5. Assuming that Paul's build
environment comes with ncurses you should be able to remove the SET
CFLAGS and SET ASFLAGS lines from reconf.cmd, find the emxomfar that is
giving you the error and change it to ar and it should build and run.
You also need to add the toolkit headers to the end of %C_INCLUDE_PATH%
and IIRC I had a conflict which I simply commented out as I was in a rush.
Dave

Dave Yeo

unread,
Sep 3, 2009, 1:08:14 AM9/3/09
to

The problem may be that CFLAGS is getting overwritten with the ones in
CONFIG.SITE
Dave

Dave Yeo

unread,
Sep 3, 2009, 2:03:23 AM9/3/09
to
On 09/02/09 10:08 pm, Dave Yeo wrote:
> The problem may be that CFLAGS is getting overwritten with the ones in
> CONFIG.SITE

Moving /usr/local/share/config.site out of the way and running make
RANLIB=echo AR=emxomfar allows the build to complete.
ranlib can't handle omf libraries and most of the libraries were being
built with ar instead of emxomfar
Dave

Alex Taylor

unread,
Sep 4, 2009, 11:30:02 PM9/4/09
to
On Thu, 3 Sep 2009 03:19:17 UTC, Gregg Young <ygk.n...@qwest.net> wrote:

> > What version of GCC do you have? I'm building with the EMX-bundled
> > version (2.8.1), and not PGCC or anything like that...
>
> I am using Paul Smedley's 3.3.5 build environment.

OK. I've never built with GCC 3.x or higher because I haven't found a
way to get it working yet. (Dave Yeo made some helpful suggestions a
while ago, but I haven't gotten around to trying them out yet.)

Basically, if you're not building with EMX+GCC 0.94d, then I'm afraid
you're pretty much on your own. :)

0 new messages