... and better XM and MOD support. Click here for details.

I have also updated the Winamp 2.x plug-in (save it in winamp/plugins, and move in_mod.dll out of the way, as usual).

Enjoy

[EDIT: just tested and fixed the MinGW and DJGPP makefiles. If you are having trouble, redownload DUMB. Note that there is a problem with early GCC 3 versions, which I don't care to fix, but it's not fatal. There is more information on this on DUMB's site, right by the downloads.]

woohooo i feel so happy:)
I'm just downloading it.

Yay!

/me will be downloading in in a few hours!

I tried installing, but:
xcopy lib\mingw\libdumb.a C:\Dev-C++\lib
file not found: libmingwlibdumb.a

But I checked the dumb/lib/mingw folder and found libdumb.a so I hope I can just copy paste it to dev-c++/lib/

[edit] Wohoo I tested dumbplay.exe. No clicks found yet, but sometimes it seems that when I use other programs at the same time the playback lags. I don't know if it counts as clicks, and don't know if it happens in games, but exellent work anyways!
[edit2] ra_ocean.it went mad after playing it about 1.5 minutes. Before that it sounded exellent, though. I hope you have any idea what the problem might be?

There's a problem in the makefile when installing the library. It happens with MSVC. You do a command like this:

copy include\dumb.h "c:\programa\vstudio\vc98\include\"

The filal '\' at the destination directory shouldn't be there. It generates an error, something like "folder not found". It should be

copy include\dumb.h "c:\programa\vstudio\vc98\include"

And the file aws_mac1.zip crashes dumb. It worked with 0.9.0, so you have broken something.

Oscar, your link is broken..

Sorry. I wrote extra ".

Solved

Listening. Hasn't crashed yet...

It crashes for me just at loading...

I'm using MSVC.

[edit]
just to make sure that the link song is the correct. The song's name is "Medieval Ambience" (or something similar)?
[/edit]

Yup. Its the right file, and it doesn't crash here, on linux. Maybe some weird MSVC bug.. Bruce will know

Oscar: Have you tried the winamp plugin?

Not yet. I'll try it.

Fladimir:

Your version of make must be escaping the backslashes. Could you type "make -v" and/or "make --version" and quote the output please? Also do you have Cygwin and/or a Unix shell installed?

Yep, along with libaldmb.a, libdumbd.a and libaldmd.a. If they're not there, run 'make' and 'make DEBUGMODE=1'. Also copy include/dumb.h and include/aldumb.h to c:\dev-c++\include.

This may be a problem with Allegro, or it may be something you can fix by increasing the buffer size (see dumb.ini).

I shall investigate.

[EDIT]
It uses too much processor power and can't keep up. The filters aren't to blame; it's the sheer number of channels. Edit dumb.ini and set dumb_resampling_quality to 1 and it should cope better. Alternatively, reduce dumb_it_max_to_mix.

Bob and I are thinking about possible replacements for the linear average algorithm that kicks in for qualities 2, 3 and 4 and uses so much processor power.

[EDIT #2]
After some experimentation, it seems the filters can also be quite processor-intensive - especially when there are 60 of them being applied at once! (This happens at the 3-minute mark.) Try reducing the sampling frequency to 22050 (exercise caution if going lower than that though - see Known Bugs). Try reducing dumb_it_max_to_mix to 32.
[/EDIT #2]
[/EDIT]

---

Oscar:

Fixed in my copy, which will be committed to CVS when I feel like it. I also changed the MinGW makefile to use the 'CP' variable (set to 'copy') instead of 'xcopy'.

I second Tom. I have broken nothing. My best guess is an MSVC optimisation bug; in addition to trying the (MinGW-compiled) Winamp plug-in, try linking with dumbd.lib instead of dumb.lib and see if it still crashes. (You can delete dumbplay.o and dumbplay.exe and use 'make DEBUGMODE=1' to achieve this.)

No he won't

How do you define 'went mad'.. I tried it and it seemed to be ok over the 2min mark.

I'm dumb!. You mean you ARNT the all knowing, all seeing Mr. Perry? n/m then.

No, I aren't.

Re ra_ocean.it, see my edit above.

Sory, I dont like single quotes

Sorry, but you missed an E out too

[EDIT] I'm mean

[edit] Im listining to that it file from above... well it still get a bit 'choppy' even on quality mode 1... does that min_to_max thing make a big difference?

[edit2] That BANG I reported earlier, It may have something to do with my SBLive. I just remembered that at 100% volume EVERYTHING is noise (well not completely, but It's hard on the ears). So I usually sit at 90% which is fine for most stuff, but it seems with DUMB It want's the volume set at 80%...

[edit3] um.. As I said 'Might'... Im not totally sure, the noise I get if the volume is to high is very staticy, or trebly... (kinda like white noise)

It's not min_to_max, it's max_to_mix, i.e. max(imum number of samples) to mix

I just set it to 64, and quality = 4, and the file played fine. Gonna try 128 now

[EDIT] It has a bit of trouble on 128, but that might be because I'm browsing allegro.cc at the same time. [/EDIT]

Setting it to low values like 8 can be... interesting

What kind of monster machine do you have? I've got an Athlon 900... And with dumb_it_max_to_mix set to 32, and quality set to 4 It gets up to 80% in the first 30 seconds of the ri_ocean.it file... heh. I saw it go up to 89.7% CPU usage.

hmm. just did a test with quality set to 1, max_to_mix set to 32.... I still get peaks of 80% CPU usage. but the overall usage is way down. I'd appreciate it if you and bob found some more time to get new reasmpling methods... I mean IT doesn't use that much CPU time playing its own fiels does it?

AthlonXP 1800+ with DDR RAM. DUMB was compiled with GCC 3.1. Which compiler did you use? You are linking with the optimised build, right? DUMB really shouldn't be going up to 80% with those options...

Oh and change "dumb_resampling_quality", not "quality". "quality" is an Allegro option.

IT is written all in assembly language, so it's Pretty Damn Fast.

Im using gcc 2.95.4 IIRC... ah. -ldumb helped (instead of -ldumbd...) but it's still getting to 40% and, it seems that I get a bit of noise with the optomized build.. You're going to say try 3.1 eh? I've got 3.0.4...

hmmm.. at about the 3min mark the usage goes right through the roof... almost 90% again.

[edit] apt-get'ing 3.2 right now...

Try removing the various optimisation flags from the makefile and see when the noise disappears. -funroll-loops is a good candidate...

But thats too much like work.

See my [EDIT #2] above.

In other news, it appears DUMB works much more efficiently compiled with GCC 3.x than it does with GCC 2.x. At least on an Athlon it does.

It's a bug in DUMB's XM loader. Expect a fix in the next release (or from CVS, if you're daring)

And, to elaborate, the bug existed in DUMB v0.9 too. It happened when the loop points were out of range (more or less). The only change is that DUMB v0.9.1 decided the sample was set to loop, and DUMB v0.9 didn't. This change was necessary for another file to play correctly.

The fix is committed to CVS now, since Bob's post was ambiguous as to whether the fix had been made yet or not

Side note: I remember nearly soiling my pants the first time I heard IT playing my (at the time) huge collection of MOD/S3M files. And when I read in the docs it was writting completely in ASM, I promptly suffered a brain aneurysm and fell out of my chair.

Having done a lot of tracking and coding for MODs and S3Ms in the past, I can appreciate the work going into this lib. Keep up the good work!

Nice
at once

I'll try it ofkoz with MultiAMP

See ya

I hope these filters will run on P166mmx

I don't want to be that bastard who corrects everyone, but ... you know, we have a little thing called a full stop that we commonly use instead of for punctuation ...

OK ...

However some stragne thing happens with Mingw:

D:\mingw32\allegro\addons\dumb>fix mingw
Configuring DUMB for Windows (MinGW)...
Done! Now run makeall or makecore to start the compilation.
D:\mingw32\allegro\addons\dumb>makeall
obj\mingw\gccver.exe > obj\mingw\gccver.inc
objmingwgccver.exe: not found
D:\MINGW32\BIN\MAKE.EXE: *** [obj/mingw/gccver.inc] Error 127
-
An error occurred. [...]

what's up?
v0.9 was compiling ok!

...

Rafal: do you have cygwin installed? What about a shell (sh.exe, bash.exe)? MinGW Make does not escape backslashes normally on Windows, so it is probably invoking such a shell, and that shell is escaping the backslashes.

Run the following command yourself:

   obj\mingw\gccver.exe > obj\mingw\gccver.inc

Then run 'make' again, and it should work. I shall think about possible ways of getting round this for the next release...

FYI, you would have had the same problem with DUMB v0.9, had you happened to want to compile it for MSVC.

I'm using Mingw only...

I also tried running make under sh but that won't fix that ...

Which version of MinGW?

I second that error. Got it as well (from CVS ...). Related to improper escaping, I think. Zsh interferes with the build process somehow. Changing the proper backslashes to regular slashes in the makefile fixed it, by the way.

But regular slashes won't work if you don't have such a shell...

Not saying it fixes it universally, just saying that it fixed it for me ...

Then that's not very helpful, is it

Maybe I should look into alternatives to GNU Make...

My mingw is now 2.0.0.3

I'm just saying that if it worked for me, it will probably work for others who have my problem, as well.

Rafal: add the following line to the top of make/makefile.mgw:

MAKESHELL := $(COMSPEC)
Be sure to use an editor that doesn't destroy tabs (i.e. don't use MS EDIT; Notepad will do fine). Then tell me if it compiles.

[EDIT: nm, Rafal's managed to compile it already (according to an e-mail), so he probably won't have any motivation to do this. X-G, could you try it plz? ]

Maybe I'll try it - no promises!

Bruce: No luck. Also, you might want to make an RM var in the makefile (much like the CP one that already exists), since "del" doesn't work in XP either.

I tested it for you - that won't work...
problem is the same...

try something other

also there is old problem with these COPYs...
and RM doesn't exist with standard mingw distro...

Minimal CYGWIN is required to use CP and RM...

Go on...

NOTE: DEL , COPY etc things built in into command.com never worked for me with Mingw!!!!

Rafal, by default, CP is set to "copy" in the makefile. The "copy" command doesn't work in windows XP, though - for that, you'd have to use "xcopy" or the "cp" unix equivalent, which is also available for windows. Similarly, "del" doesn'tt work in XP, but can be replaced with "rm" if you have it.

Try plain old 'SHELL' instead of 'MAKESHELL'.

I'm tooooooo lazy to do so