Apparently-To: john.smith@gravis.com


GUS Programmer's Digest     Wed, 9 Mar 94 17:06 PST      Volume 9: Issue  25  

Today's Topics:
                       Background MOD playing.
                               clipping
               GUS Programmer's Digest V9 #24 (3 msgs)
                       Just a few questions....
                             Miles Driver
                           Re[2]: clipping
                   Simultaneous recording/playback

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: Wed, 9 Mar 1994 15:05:40 -0800 (PST)
From: wyatt cheng <wyattc@sfu.ca>
Subject: Background MOD playing.

Can anybody suggest to me a technique for playing MOD files in the
background of a game?  Examples are Tetris Pro and UltraWlf, and no
doubt all the other games use the same technique for playing their own
music files in the background.

So the problem reduces to, how do I play music files in the
background?

I was thinking of hooking the timer interrupt, but since this only
clicks 18.2 times a second, would the music come out with erradic
timing?



wyattc@sfu.ca

------------------------------

Date: 9 Mar 94 08:06:00 MET
From: "VISX80::GRECNER" <GRECNER%VISX80.decnet@musx53.zfe.siemens.de>
Subject: Re: clipping

> It would be very strange, if there's no such algoithm, in my opinion.

>No, it's not strange. If there was, then it would be a feature called a
>limiter, something that's not present on the GUS, since i can if i want

Limiter would be almost the same problem...

>make it clip both in the digital and analog domain. However, if you cant
>learn to mix properly on the GUS, you'd have the same problem on an analog
>setup with a mixer. Even if you can get an analog limiter, it is a bad

I can't agree here. Analog mixers have much greater dynamic range. It's
not the same result if I reduce 16-bit sample to 8-bits and if I turn
the mix volume on an analog synth down to get the same dB effect.
In digital you are dealing with discrete levels, the only problem in
analog is the linear distortion and noise, which is minimized in
good devvices.

>thing to make it work continuously. The sound will be muddy and wont
>have any dynamic range at all. Now, if you have a digital limiter, the
>same problem will happen: no dynamic range and a muddy sound.

That's clear... I wasn't asking for limiter, I was asking if it's clipping
or limiting what takes place in GUS, or something else... Any of these
two possibilities is not very satisfying...

>limiter circuit. And what about MOD files! Talk about MASSIVE digital
>clipping! Still, there are some people who still listen to these...

Sure, but what does it say ? There are many people listening to the
pocket radios as well ;-)

>> In this case, it's statistically really not so bad. But I still think
>> it can't just clip the wave to the maximum voltage until the sum of
>> all voices becomes less than the maximum...

>Why not?? If you had 32 16 bit DACs connected to a mixer and drove all of
>them peak to peak, you'd get clipping in analog. Either you add voltages
>or values, the result is the same. In analog, you are limited to 2 volts,
>in digital 16 bits. As simple as that. There is no way to avoid this
>limit.

I really don't think it's the same. If you are limited to 2 volts, you
still have virtually infinite number of "steps" from 0 to 2 volts. In
digital you have only few levels compared to it. The dynamic range
(understand ratio between the most silent and most loud signal the device
can produce) is to be taken different in digital. Let's say you have a
2-bit signal, which implies a dynamic range of 3 dB. But you have so
much harmonic distortion then... In analog, you have to deal with noise,
instead...

>Yes, you have to mix. It's not a question of hoping, it's a question of
>not driving every sample at 127. At 100, you are at -6dB to give you an
>idea...

O.K. I'll give up here. GUS has simply only 16 bit DACs, so nothing can
be done about it. The only solution is to use 18 or even more bit DACs,
but I agree that for the price of the GUS I can't have everything...

				Thanks for comments
				Martin

------------------------------

Date: Tue, 8 Mar 1994 21:37:58 -0500 (EST)
From: Phat H Tran <ptran@sciborg.uwaterloo.ca>
Subject: Re: GUS Programmer's Digest V9 #24

> Date: Tue, 8 Mar 1994 12:11:40 -0700 (MST)
> From: "Shawn T. Rutledge" <rutledge@enuxsa.eas.asu.edu>
> Subject: Re: GUS Programmer's Digest V9 #23
> 
> > really only me who can assign apropriate volume settings to all the
> > instruments hoping the probability of not exceeding the maximum is
> > great enough ... I don't like it, however. Aren't here any documents
> 
> I don't either.  The idea of using 21-bit math and dividing down to
> 16 bits sounds better to me.  Or using a DAC with greater than 16-bit
> resolution...

Trust me...  using 21-bit math and dividing down to 16-bit won't sound
as good.  It will, in fact, sound much worse.  A good analogy is the
way MOD players have to deal with adding up 4 8-bit channels for an
8-bit DAC.  Old MOD players added the 4 channels up in a 10-bit
accumulator and then divided the accumulator to get an 8-bit value.
This resulted in much reduced dynamic range, and the divisor is only 4!
Nowadays, most MOD players have a "quality" mode in which they don't
divide the accumulator.  (Of course, GUS MOD players have never had to
worry about these details.)

> Date: Wed, 9 Mar 1994 08:05:05 +1000 (EST)
> From: s921880@minyos.xx.rmit.EDU.AU (Adam Craig Seychell)
> Subject: Re: GUS Programmer's Digest V9 #23
> 
> If the GUS mixes the 32 voices simply by summing the samples ( digitaly )
> then why is the Ultrasound limited to 20KHz sample rate when playing 32
> voices.  I first thought that it was because DAC might no beable to keep
> up but now I know that mixing is done in the digital circuits, adding 32
> samples at 44KHz should be a piece of cake.  

I think you're forgetting the fact that the GUS also has to interpolate
points, scale samples, pan voices, ramp volumes, and increment pointers.

> Date: Tue, 8 Mar 94 18:16:24 EST
> From: Dan Liszewski <liszewsk@lf.hp.com>
> Subject: simultaneous play & record
> 
> Forgive my ignorance but, I'm wondering if the GUS could support
> simultaneous play and record.  Is it possible, or is there something
> about the card that won't allow it?

Yes, the GUS can.  Dave McMahon's (sorry if I butchered your last 
name, Dave -- Mc vs Mac) gusdelay program demonstrates simultaneous
playback and record quite well.

Phat.

------------------------------

Date: Wed, 09 Mar 1994 09:46:50 -0500
From: davidm@marcam.com (David MacMahon)
Subject: Re: GUS Programmer's Digest V9 #24

>Date: Wed, 9 Mar 1994 08:05:05 +1000 (EST)
>From: s921880@minyos.xx.rmit.EDU.AU (Adam Craig Seychell)
>Subject: Re: GUS Programmer's Digest V9 #23
>
>If the GUS mixes the 32 voices simply by summing the samples ( digitaly )
>then why is the Ultrasound limited to 20KHz sample rate when playing 32
>voices.  I first thought that it was because DAC might no beable to keep
>up but now I know that mixing is done in the digital circuits, adding 32
>samples at 44KHz should be a piece of cake.  
>This means the DRAM will have to transfer at a rate of 44100*2*32  bytes
>per second. Which is fairly slow for 100ns DRAMs.

The GUS "processes" a voice every 1.6 microseconds (approximately).  
Processing a voice involves interpolating a sample (so two memory accesses), 
calculating any volume ramps, applying the volume to the voice, applying pan 
position, and adding the resulting value into a "running sum" register (and 
I probably even forgot a few things).  After the GUS has processed all the 
used voices, it sends the "grand total" to the DACs.  The 1.6 usec figure is 
actually 1/(14*44100) seconds, whatever that works out to be.  This is part 
of the hardware design of the GUS and can not be changed.  This allows the 
GUS to update a voice every N/(14*44100) seconds, where N is the number of 
voices in use.  If fourteen voices are being used, each voice gets updated 
at a rate of 44100 Hz.  If more than 14 voices are used, the time between 
successive updates of a particular voice increases, thereby decreasing the 
rate at which the voice is updated.

I don't know how often the DACs are updated.  Given the scenario above, the 
DAC's would be updated every N/(14*44100) seconds.  It may be, however, that 
the "running sum" is not recalculated from scratch every time through.  The 
GF1 may subtract a voice's old value from the running sum before adding its 
new value.  This would allow the DAC's to be updated every 1.6 microseconds. 
 Or, better still, the GF1 could have a giant adder with 32 latched inputs 
of 16 bits each.  That way, the "running sum", the adder's output, could be 
fed directly to the DACs.  This would update the DACs every 1.6 
microseconds.  I think, though, that my original scenario is probably 
correct.  Does anybody know for sure?

Dave

David MacMahon
Software Engineer
davidm@marcam.com

------------------------------

Date: Wed, 09 Mar 1994 10:01:56 -0500
From: davidm@marcam.com (David MacMahon)
Subject: Re: GUS Programmer's Digest V9 #24

>Date: Tue, 8 Mar 94 18:16:24 EST
>From: Dan Liszewski <liszewsk@lf.hp.com>
>Subject: simultaneous play & record
>
>Forgive my ignorance but, I'm wondering if the GUS could support
>simultaneous play and record.  Is it possible, or is there something
>about the card that won't allow it?
>
>Thanks
>Dan Liszewski

The GUS can definitely support simultaneous play and record.  My program 
GusDelay takes advantage of this feature to turn the GUS into a digital 
delay unit.  The latest released version is 0.3 (GUSDLY03.ZIP in the 
archives).  I am *very* close to releasing version 1.0.  The code is all 
done (except for one ancillary feature I want to add) and I am working on 
the documentation (including a "Theory of Operation" chapter).  As soon as I 
finish (hopefully this weekend), I will upload it to epas and maybe a few 
other places (epas seems to "lose" submissions occasionally).  When I upload 
it, I will send a message here.  You can get version 0.3 in the mean time, 
but don't expect too much; it's not too good.  Version 1.0 is totally 
re-written (well, mostly) and is amazingly superior to version 0.3 This is 
MHO, of course, but when you see version 1.0 I think you'll agree! :-)

Dave

David MacMahon
Software Engineer
davidm@marcam.com

------------------------------

Date: 8 Mar 94 20:46:00 PST
From: "Midnight Cowboy" <LDANG@csupomona.edu>
Subject: Just a few questions....

QUESTION #1:

I just started messing with the SDK to get some sound out of the GUS in
Borland C Large Model...

My proggy takes input from the keyboard, and allows the user to move a small
marker around the screen (moving left or right).  To play a sample (WAV file)
loaded in the GUS DRAM, the user has to hit the spacebar.  I set the pan
position for that particular channel based on the marker's position on the
screen (i.e., extreme left of the screen = 0; extreme right = 15).

Initially, I open the GUS with 32 digital channels.  I'm using UltraPrimeVoice
and UltraGoVoice to play the samples.  Channel_num is the current channel being
played, and is initially set to 1.  When the user hits the spacebar, it plays
the sample on channel #1, and increments Channel_num.  If Channel_num is > 32
then it's reset to 1.  All of this is done in a loop until the user hits "Q" to
quit.  Thereby allowing the user to depress the spacebar to play the sample
on up to 32 channels simultaneously.

However, the channels get corrupted after a little while and all I get are
clicks!  The way I solved this was to use a small loop within my main loop:

for (i=0; i < 32; i++)
{
   if (UltraVoiceStopped(i))
      UltraSetLinearVolume(i, 0);
}

As I understand it, all the voices are summed into the final output even if
I'm not using it.  So I have to set the volume to 0 after I finish with any
particular voice.

Is this the right way to accomplish this?  Or am I going about this all wrong?


QUESTION #2: (pertains to the same proggy)

(My GUS is hooked up to a ProLogic Surround reciever)

Now, if the marker is at the extreme left of the screen (pan position 0), and
hits the spacebar, then jumps to the right side of the screen and plays the
same sample again (pan position 15), the sample is played out of the surround
speakers!

Why is that?  From what I understand of surround sound, to play the sample
out of the surround speakers, you must play the sample on two channels---but
on one channel, play the sample normally at pan position 0 or 15, and on the
other channel play the sample inverted (180 out of phase, or negate it) on 
the opposite pan extreme.

Are the two channels some how cancelling each other out when the voices are
summed for output?  Reason I ask is because I plan to add surround sound 
into my proggy, but I gotta get rid of this side effect first...

QUESTION #3:

I tried to re-compile the same program above using Watcom C 9.5, with the
flat memory module provided in the SDK.  It compiles and links fine, but when
I hit the spacebar (to play a sample/WAV file), I get nothing! (aside from
'clicks')

I suspect it could be the way I'm allocating system memory (since I originally
used Borland C Large Model), and Watcom might not like the way I'm doing this.

Or do I have to recompile the libraries for version 9.5?

Just a few questions from a beginner,

==========================================================================
"From loss and grief the Mind has become deranged.  Therefore we, as parts
of the Brain, i.e. the Mind, have become partly deranged."  --- PKD

Steve Dang				    internet:  ldang@csupomona.edu
Church of Valisology				 irc:  boomshaka
Author: "The Book of the Foot", "Reality...and then some"
==========================================================================

------------------------------

Date: Wed, 9 Mar 1994 09:19:16 +0800 (CST)
From: b2502056@cc.ntu.edu.tw (b2502056)
Subject: Miles Driver

> Date: Tue, 1 Mar 94 23:20:44 GMT
> From: bre@os.is (Bjarni R. Einarsson)
> Subject: Shareware/Commercial.. DIGPAK?
> 
> Does Shareware qualify as COMMERCIAL software?  I grabbed the DIGPAK and
> MIDPAK kit, and looked at it.. I wanna use it!  Am I *allowed* to?  Or 
> do I have to pay $1000 for it?  
You doesn't need to pay $1000 if you only use it for yourself.
If you make them public, you may pay for it.

And, I`m playing MIDPAK.ZIP, but can't find DGMID.ZIP. If you have DGMID.ZIP,
can you upload to some FTP SITE (like archive.epas.utoronto.ca). Thanks !!!!!

______________________________________________________________________ 
                         | Taipei,Taiwan,ROC |     \   /  /////  /   / 
    ______               ^^^^^^^^^^^^^^^^^^^^^    / \ /    /    /   / 
   / ~  ~ \                                      /   \    /    ///// 
  |  O  O  |    Whatever the world becomes, 
  |   ^^   |    play your own role, be yourself. 
   \__()__/                                         ::: Howard Yeh ::: 
                                                b2502056@cc.ntu.edu.tw 
______________________________________________________________________ 
 

------------------------------

Date: 9 Mar 94 08:26:00 MET
From: "VISX80::GRECNER" <GRECNER%VISX80.decnet@musx53.zfe.siemens.de>
Subject: Re[2]: clipping

>> And dangerous for the sound. But I like the idea of signed approach

>What do you mean by signed approach?  That the 16-bit number represents

I mean I was doing calculations from 0 to 65535 instead of -32k to +32k,
forgetting the DC part of the signal assuming then analog capacitor
for filtering it. I was wrong, that's all I wanted to say :-)

>> really only me who can assign apropriate volume settings to all the
>> instruments hoping the probability of not exceeding the maximum is
>> great enough ... I don't like it, however. Aren't here any documents

>I don't either.  The idea of using 21-bit math and dividing down to
>16 bits sounds better to me.  Or using a DAC with greater than 16-bit
>resolution...

yes, here we share exactly the same opinion. But, it's more expensive
technology then, unfortunately :-(

>I suspect that the reason it isn't a problem is that our current set of
>samples has few if any full 16-bit peaks.  The full dynamic range isn't
>being used anyway; if it was, clipping would occasionally occur.  Besides,

Yes, that's absolutely true. For exmple the drum set is awfull. I was
trying to play with volume sliders in the with GUS supplied sequencer
to make sample songs sound better, but without any significant success.
I have to stop using and start developing. I have an idea of completely
new MIDI driver for the GUS, using Ensoniq patches  instead of .pat format.
But for now I'm unable to find any example of a MIDI driver for Windows.
(Any pointers welcome). I'd like to have GUS responding to poly-aftertouch
and key pressure, as well. Even if there is something like layers defined
in patch.h of GUS SDK, I can't find there any information on how they
are triggered, and I suspect they don't work at all with current MIDI
driver.

>11 bits, that is probably closer to its real-life dynamic range, and
>we should think of the 16 bits as extra headroom for cases when instruments
>pile up on top of each other and the amplitude is reinforced.

Well, that's what we're left with. :-(

				Thaks for comments
				Martin

------------------------------

Date: Wed, 9 Mar 94 11:16:09 EST
From: support@fortech.com (Technical Support)
Subject: Simultaneous recording/playback

> From: Dan Liszewski <liszewsk@lf.hp.com>
> Forgive my ignorance but, I'm wondering if the GUS could support
> simultaneous play and record.  Is it possible, or is there something
> about the card that won't allow it?

The only thing preventing simultaneous playback and record is software.
The SDK can be used to create your own dos-based tool to do it, or
you could wait for the new windows drivers to be released. They are
in beta test now, and should be available in a couple weeks (assuming
no major problems are found.) The windows drivers for the UltraMax
(also in beta) already support it. 2 DMA channels will be needed.

On another subject:

> From: s921880@minyos.xx.rmit.EDU.AU (Adam Craig Seychell)

> If the GUS mixes the 32 voices simply by summing the samples ( digitaly )
> then why is the Ultrasound limited to 20KHz sample rate when playing 32
> voices.  I first thought that it was because DAC might no beable to keep
> up but now I know that mixing is done in the digital circuits, adding 32
> samples at 44KHz should be a piece of cake.  
> This means the DRAM will have to transfer at a rate of 44100*2*32  bytes
> per second. Which is fairly slow for 100ns DRAMs.

DRAM speed isn't the limiting factor. The dedicated DSP in the GF1 can 
only run so fast. It can only do 14 voices as 44.1. As it needs to service 
more voices, it can't update the DAC's as often. By servicing a voice, I mean
that it has to do the interpolation, update the current location, do balance
and volume ramps, update status etc. It takes approx 1.6 microsecs to do all
that per voice.

Adding up 32 samples would be very quick. Its all the other stuff it needs 
to do that takes up the vast majority of the time.

Forte Tech Support

------------------------------

End of GUS Programmer's Digest V9 #25
*************************************

To post to tomorrow's digest:                    <gus-sdk@mail.orst.edu>
To (un)subscribe or get help:            <gus-sdk-request@mail.orst.edu>
To contact a human (last resort):          <gus-sdk-owner@mail.orst.edu>

FTP Sites              Archive                       Directories
---------              -------                       -----------
Main N.American Site:  archive.orst.edu              pub/packages/gravis
                       wuarchive.wustl.edu           systems/ibmpc/ultrasound
Main Asian Site:       nctuccca.edu.tw               PC/ultrasound
European Callers ONLY: theoris.rz.uni-konstanz.de    pub/sound/gus
Submissions:           archive.epas.utoronto.ca      pub/pc/ultrasound/submit
Newly Validated Files: archive.epas.utoronto.ca      pub/pc/ultrasound
Mirrors:               garbo.uwasa.fi                mirror/ultrasound
 
MailServer For Archive Access: Email to <mail-server@nike.rz.uni-konstanz.de>

Hints:
      - Get the FAQ from the FTP sites or the request server.
      - Mail to <gus-sdk-request@mail.orst.edu> for info about other GUS
	related mailing lists (general use, musician's, etc.).



