GUS Programmer's Digest Sat Jun 19 00:07 Volume 2: Issue 17 Today's Topics: General stuff GUS PROGRAMMER'S DIGEST WAV Standard Info: - Meta-info about the GUS can be found at the end of the Digest. - Before you ask a question, please READ THE FAQ. ---------------------------------------------------------------------- Date: Fri, 18 Jun 93 09:29:10 EST From: devel@fortech.com (UltraSound Developer Support) Subject: General stuff Message-ID: <9306180929.0.UUL1.3#16204@fortech.com> Hello there, I have been out of town for a few days and have not been able to keep up with some of the questions/comments that have been posted here. I'll try and answer as many as possible now. =================================================================== > Why can't Gravis create an SBOS program to emulate Sound Blaster Pro? > What's so hard about doing that? Won't it be like SBOS except that it must > keep track where to play which instrument? > It would be nice if Gravis Ultrasound can also emulate the Sound Blaster > Pro. I don't mind whether GUS can or cannot emulate SB-Pro. I was just > wondering. > George Montemayor > The hardware necessary to emulate SB-Pro is not on a GUS. =================================================================== > Date: Mon, 14 Jun 1993 15:18:17 -0500 (EST) > From: James Reutter > Subject: SDK with MS QuickC > .... > We're using the latest SDK (version 2.01, which we ftp-downloaded), > calling routines from the ultra0lm.lib and ultra1lm.lib. The C compiler > we're using is Microsoft QuickC, version 2.50a. The toolkit libraries for Microsoft were for C 6.0. I don't know if they would work for quick C. I would suggest re-compiling the libraries to use with your compiler. > However, when we made virtually identical calls to the new SDK, the > sound quality is highly degraded (very staticky). Highly degraded sound quality is usually a set up problem. One of the parameters for the data type is probably wrong. Check either 8/16 bit data or twos compliment. .SND files are generally one's compliment (binary offset) . The GUS ONLY plays back twos compliment data, so you must make sure you specify the correct format so that a translation can be done while it is being DMA'ed. I don't know what the rest of your problems are. Looks like some kind of logic flaw. I know that's not real helpful, but that is what it looks like. =================================================================== > Date: Tue, 15 Jun 93 10:20:12 EDT > From: davidm@opl.com > Subject: Gravis/FORTE - Please read this!!! > ... > The first point is what was causing the problem I had with looping and wave > table interrupts. If I set up a voice with looping and WITHOUT interrupts, > everything behaved as expected. If I set up a voice with looping and WITH > interrupts, the voice would play from start to end and then stop - no > looping. This was driving me crazy (for quite some time, I might add) until > I looked in IRQ.C and saw the following... > if (!(wave_ignore & voice_bit)) > { > UltraStopVoice(voice); > wave_ignore |= voice_bit; > > /* Call waveform processing function.... */ > _gf1_data.wavetable_func(voice); > } This is put in here for two reasons. If IRQ's are enabled for the voice and looping is NOT enabled, the voice must be stopped so that continuous IRQs are not generated. The IRQ is generated as long as they are enabled for a running voice and the current position = end position (or start pos if going in reverse). If looping is NOT on, that condition will be met all the time until the voice is stopped or the IRQ is disabled. That is why the UltraStopVoice call is made. If it were not made, an application may get may more IRQs than expected, since then it would be its responsibility to shut it off. Yes, it is true that the application MUST restart the voice if it wants to get an IRQ at the end of a wave and then loop back and continue the sample. I suppose the irq handler could be changed so that if looping were on, the voice would NOT be stopped requiring the app to restart it. I'll dig into it a bit deeper, but I don't see any reason why I can't incorporate it into the SDK. > You neglect to mention this fact in the SDK documentation (thank you, NOT!) > or at least I couldn't find reference to it. This may be the first, but will CERTAINLY NOT be the last thing the is not fully explained in the documentation. It is not possible to explain every case and scenario that may occur. As we find them, we will make note of them in the SDK. For now, that is one of the main reasons that the source code was distributed. It makes it possible for the developers to find some of the idiosyncrasies of the card. There were main other suggestions (most of very good ones) that will be considered. I agree that the rollover bit was neglected in the implementation. There are historical reasons that I won't go into because they are no longer relevant. We should be able to accommodate the types of functions you want, but I am not sure exactly the best way to implement them. For not, you have access to the source, so you can do it any way you like. (Though I realize that may cause problems with things when a new toolkit is released.....)BTW, I am sure a new one will be released, I just don't know when it will appropriate. Any RESONABLE suggestions will be considered, so you may want to post things to the this digest. They may or may not be used, but since you folks are the ones trying to use it, we certainly can use the feedback. At some point, I'll post a list of things that I know will be (or have been) done to it. =================================================================== Several people have made mention of a 'Pro' toolkit. That is a high level toolkit (available from Gravis with an NDA) that has very little bearing on the lowlevel stuff. It is primarily used by people who need to do music level applications. It has more note on, note off , patch type of calls. The source to the high level SDK is NOT currently available even with the NDA. =================================================================== Hope some of this info helps. Forte Tech Support ================== ------------------------------ Date: Thu, 17 Jun 93 18:57:23 From: john.smith@gravis.com Subject: GUS PROGRAMMER'S DIGEST Message-ID: <9306171857.A3549wk@gravis.com> G>---------------------------------------------------------------------- G>Date: Wed, 16 Jun 93 8:39:59 EDT >From: Peter G.N. Scheyen >Subject: Re: Gravis/FORTE - Please read this!!! >Message-ID: <9306161240.AA19711@mccarthy.csd.uwo.ca> G>Firstly, I guess you didn't read the disclaimer about support -- none to >speak of. Secondly, what did you expect for free? If you want a proper >SDK get the professional one and sign the disclaimer. G>Pete >scheyen@csd.uwo.ca G>------------------------------ We did read it. The person who did the SDK at Forte is away until early next week. I've printed out yesterdays digest and will be passing it along to him. John --- ~ QMPro 1.02 05-8925 ~ Dogs come when you call. Cats have answering machines. ------------------------------ Date: Fri, 18 Jun 93 01:15:47 CST From: "Pawlo P Prawdiuk-1" Subject: WAV Message-ID: <344.praw0002@student.tc.umn.edu_POPMail/PC_3.2.2> Could someone tell me / or ul a description of the std windows 3.1 wav file format thanks.. oi! thanks! praw0002@student.tc.umn.edu ------------------------------ End of GUS Programmer's Digest V2 #17 ************************************* To post to tomorrow's digest: To (un)subscribe or get help: To contact a human (last resort): FTP sites: archive.epas.utoronto.ca pub/pc/ultrasound wuarchive.wustl.edu systems/msdos/ultrasound Hints: - Get the FAQ from the FTP sites or the request server. - Mail to for info about other GUS related mailing lists (UNIX, OS/2, GUS-MIDI, etc.)