Apparently-To: john.smith@gravis.com


GUS Programmer's Digest     Thu, 21 Oct 93  4:00 MDT     Volume 5: Issue  17  

Today's Topics:
                          Coding for the SDK
    DIGEST ADMIN: PLEASE SEND YOUR REQUESTS TO THE RIGHT PLACE!!!
                        MIDI file description
                          subscribe (3 msgs)
                     Tune parameter in patch file

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, 20 Oct 93 05:57:02 PDT
From: deraud@power.amasd.anatcp.rockwell.com (Robert Lee DeRaud)
Subject: Coding for the SDK

>Date: Tue, 19 Oct 1993 03:31:41 -0400
>From: Greg Chung <gchung@eden.rutgers.edu>

>I've got a simple question regarding the SDK.  I am, of course, using the
>high-level C routines in my C program.  However, the size of my executable
>recently swelled over the 90K mark.  I know most of this is due to C overhead,
>such as my use of the time() function.

Dunno about time() specifically, but most library functions are 
optimized up the wazoo anyway: flab in the standard functions tends to 
have a VERY bad effect on the compiler vendor's reputation. Generally, 
the executable size is affected MUCH more by compiler/debug options etc. 
What compiler and switch settings are you using? Also, how much memory 
does your program actually USE when loaded? (Executable files compiled 
for debugging include a LOT of symbol table data that is NOT loaded when 
running whithout the debugger: all it costs is disk space.)

>I trimmed out as much of the GUS .c files as I could (the MIDI/joystick and
>record functions, mostly), but the size of the GUS .obj's is still large.  Is
>there an easy way to trim down the size of these functions?  My guess is that
>all the inport()'s are adding up, but I don't really know enough assembly to
>handle things like interrupt callbacks and DMA etc. 

Same comment for .objs as for .exes. I haven't had time to look at the 
actual SDK code yet (all hell broke loose here at work about the time I 
got it :-(), but assuming the functions in the documentation are 
arranged semi-intelligently in the files/libraries, you'll only pick up 
the stuff you NEED at link time anyway. BTW, calls to inport()/outport() 
are very cheap, resource-wise.

>Any suggestions would be appreciated.  Actual .ASM code converted from exact
>C functions would be ideal...  I can't figure out what shortcuts are being
>taken in things like gusmod, etc.

You can always (at least in any decent C compiler) make the compiler 
output assembly code and then hand-optimize it and assemble it 
separately. Note that the payback for this hassle is a lot less than you 
would expect: the name-brand compilers already put out pretty good code.
Source code for a mod player was floating around on EPAS awhile back...
file was named 'gusmpsrc.zip' or some such. Dunno if it is the source to 
gusmod or something else, but it's better than nothing.

>Thanks!
>Greg

***********************************************************************
Lee DeRaud                             Will program Windows for food.
Rockwell Int. AESD                   (Hey, I'm easy but I'm not cheap!)
   DoD #985 - Fast and ugly beats slow and cute any day of the week.
 ----------------------------------------------------------------------
      My own opinions only, not those of Rockwell International.
   (Yeah, right: like anyone around here cares what *I* say...NOT!)
***********************************************************************

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

Date: Wed, 20 Oct 1993 17:06:25 -0600 (CDT)
From: ddebry@grue.dsd.ES.COM (Dave DeBry)
Subject: DIGEST ADMIN: PLEASE SEND YOUR REQUESTS TO THE RIGHT PLACE!!!

	In every digest today you're going to see a lot of (nearly)
empty messages, where the subject is "subscribe" or something like
that. 

	This means that someone wasn't paying attention.

	YOU ***MUST*** SEND YOUR REQUESTS TO THE REQUEST LINE, NOT THE
NORMAL LINE.  THE NORMAL LINE IS FOR POSTS ONLY.

	If you tried to subscribe to a list and haven't received any
mail saying you've been added to the list, it's probably because you
sent your request to the wrong place.  Try again.


-- 
Dave  ddebry@ debry@   \ 
DeBry dsd.    peruvian. | "Deduct the carrots from your pay,
      es.     cs.utah.  |  You worthless swampy fool."
      com     edu      /  

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

Date: Wed, 20 Oct 93 7:39:30 CDT
From: cowles@hydra.convex.com (John Cowles)
Subject: Re: MIDI file description

I think you'll find a midi file description on ucsd.edu.

I am aware that some time ago I promised to upload a list of
midi controllers, but have not done so yet - they're still coming;
I've been quite busy... Hopefully this week!
-- 
     John Cowles        cowles@hydra.convex.com
                        Convex Computer Corp.  214 497 4375
                        3000 Waterview Pkwy
                        Richardson, Tx. 75080

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

Date: Wed, 20 Oct 93 12:17:05 GMT
From: harri@rhi.hi.is (Haraldur D Thorvaldsson)
Subject: subscribe

subscribe!
-- 

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

Date: Wed, 20 Oct 93 9:17:25 EDT
From: ulmer@churchill.ColumbiaSC.NCR.COM
Subject: subscribe



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

Date: Wed, 20 Oct 1993 10:07:18 +22311151 (CDT)
From: read@utpapa.ph.utexas.edu (Dave Read)
Subject: SUBSCRIBE

subscribe read@utpapa.ph.utexas.edu

-- 
Dave Read   (read@utpapa.ph.utexas.edu)      "When in doubt, sheet it out."
UT-Austin High Energy Physics Grad Student 
PGP public key available by 'finger'              G O   B R A V E S ! !

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

Date: Wed, 20 Oct 93 10:49:17 EST
From: support@fortech.com (Technical Support)
Subject: Tune parameter in patch file

Hi folks,

I talked to some people here about the tune parameter in the patch files
and here is the basic response.

The tune field has been obsolete for quite a while. (since around late '92)
Originally it was used to attempt to keep a sample in tune as it was 
moved up and down notes. The whole concept was wrong and has been corrected.
Since we don't want to change the patch structure, the field was left in
but is not referenced by any current software. The only software that may
attempt to use it would be stuff from the ORIGINAL high level SDK. VERY
few people have that and as far as we know, nobody is attempting to use
it in an application. We have tried to steer people toward the lowlevel
SDK or UltraMid. That software is MUCH better and is being updated
quite frequently with enhancements and bug fixes.

Hope this helps.

Forte Tech Support.

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

End of GUS Programmer's Digest V5 #17
*************************************

To post to tomorrow's digest:                    <gus-sdk@dsd.es.com>
To (un)subscribe or get help:            <gus-sdk-request@dsd.es.com>
To contact a human (last resort):          <gus-sdk-owner@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@dsd.es.com> for info about other GUS
	related mailing lists (general use, musician's, etc.).



