JGMOD uses the same function name as Allegro and
it generates conflicts compiling 4.1.1 when grabber is extended by JGMOD's stuff!

Probably [?] when you use SAVE_SAMPLE when JGMOD is linked your program will not compile!

How about that?:-/

Try emailing the author of JGMOD and asking if he can change it. Failing that, simply rename all instances of 'save_sample' in JGMOD to something else.

Sorry about that, I don't use JGMOD (I'm the one who added save_sample).

Maybe it would be a good idea to start using the al_ prefix for new routines ?
(I have the feeling that Peter will jump in and say "no new routines!" )

I think adding "al_" now for functions would look a bit corny and only add to the lack of consistancy in Version 4.X ...

Thanx for help guys

That's good idea to check existing libraries for function names before adding new functions to ALLEGRO!

Have you considered switching to DUMB? It lacks MOD support and gives you very little control over playback, but it has better sound quality, is more faithful to the original trackers (I think...) and, most importantly, supports IT

(Sorry, couldn't resist )

Ben, we all forgive you! as long as MOD, and better playback control are added!

Thanks Ben - DUMB isn't too good! REALLY!
I use it in my Multimedia player - MultiAMP for DOS only because i haven't found anything else that supports Impulse Tracker. JGMOD RULEZ THE GLOBE!
DUMB is very slow... and it have stupid structs...
it can't support MOD... it can't detect lenght of
module... It can't display tech info like JGMOD...
so wot?

So, are you paying me for it?

I'm aware of most of the problems you've mentioned, and I'm planning on fixing them. However, your comments about DUMB's speed worry me. Can you give me some figures, and tell me what environment you're working under? What processor, what compiler, how many samples you're trying to play at once, etc.

Note that DUMB defaults to a very expensive resampling algorithm that a modern computer will have little trouble with (for a reasonable number of samples) but an older one will. You may like to try speeding it up by doing this:

dumb_resampling_quality = 1;

See dumb/docs/dumb.txt for info on what the different values mean.

One more thing - what exactly is stupid about DUMB's structs? Just the names, or what they're used for? There is a good reason to separate the structs out in the way that JGMOD doesn't - it allows you to have the same piece of music playing from two positions at the same time (seldom useful but there if you need it). I'd appreciate comments a little more constructive than "stupid", if you'd be so kind.

Hey, Ben

My config is:
Pentium 166@187.5
80MB RAM
i'm using Mingw 1.1 (gcc 2.95.3) and DJGPP v2.03 with gcc 2.95.3

Almost any IT mod which uses 10+ samples at once causes sound skipping with buffer=16384,resampling=4 and
mixing=44100.
some songs causes skipping with my MultiAMP when
I seek them.

Stupid structs:
hmm... I mean that DUMB isn't storing technical
info about mods in its structs...

so what's next?

As I said, you'll get much better performance (and lower quality but still as good as Allegro's mixer can do) by changing resampling to 1. The 4 setting is designed for advanced processors like the P4 and Athlon (see the comments at the top of dumb/src/helpers/resample.c if you're interested in this).

I am, at this very moment, working on a system to make seeking much faster. The same system is going to calculate the length. So there is hope

That's because DUH structs are universal, as suggested by the U (Dedicated Universal Harmony). They can also store OGG files, and anything else you throw at them, provided an add-on is available for it.

What info exactly did you want stored in the DUH struct? I am planning on adding author information, but not much else. There will probably be module-specific functions to probe a DUH for extra information like how many samples, that kind of stuff (and they might crash on non-module DUHs, I've yet to decide exactly how to implement them) - and there'll be callbacks when various things happen. There will also be means to adjust playback, e.g. speed it up. In the end it should be possible to construct an example as fully functional as JGMOD's.

However, if you want to see the true (as yet undocumented) strengths of DUMB, try TeleHack. It does need a good processor though (owing to TeleHack's design, not DUMB's).

The next version of JGMOD will have renamed function to erase the conflict.

SORRY... i was in hospital last week - no posts were made

OK GUYS!
so this topic is closed...

thanks for help from YOU!