From mailserv@dsd.es.com Sat Jun 19 03:38:08 1993
Date: Sat Jun 19 00:07:03 1993
From: gus-sdk-request%itchy@dsd.es.com (GUS Programmer's Server)
Reply-To: gus-sdk%itchy@dsd.es.com (GUS Programmer's Digest)
Subject: GUS Programmer's Digest V2 #17

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 
> <gmontem@eis.calstate.edu>

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 <jreutter@silver.ucs.indiana.edu>
> 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 <scheyen@csd.uwo.ca>
 >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" <praw0002@student.tc.umn.edu>
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:               <gus-sdk%itchy@dsd.es.com>
To (un)subscribe or get help:       <gus-sdk-request%itchy@dsd.es.com>
To contact a human (last resort):     <gus-sdk-owner%itchy@dsd.es.com>

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 <gus-sdk-request%itchy@dsd.es.com> for info about
	other GUS related mailing lists (UNIX, OS/2, GUS-MIDI, etc.)


