GUS Programmer's Digest Fri Jul 30 00:07 Volume 2: Issue 31 Today's Topics: GUS Programmer's Digest V2 #30 SDK questions WARNING: Lists running blind for a week... 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: Thu, 29 Jul 1993 12:51:56 -0400 From: jericho!gord (Gord Wait S-MOS Systems Vancouver Design Center) Subject: Re: GUS Programmer's Digest V2 #30 Message-ID: <9307291651.AA04444@smos.bc.ca> RE: SDK questions: The only question I can help you on is the centerpoint. I beleive the centerpoint to be 80 hex. I don't know if there is an "official" spec on this. Note that if you use USS8 and fade a section of audio to completely 0, that it ends up at 80 hex. Note also that the GUS's 8 bit in ports are not well zero'ed. My card zero's out at 7e (left channel) and 81 (right channel). Other peoples cards are different. I wrote a little test and fix program (sndfix.zip in the archives) to find out what your card is set to, and then use the program as a filter to correct samples after they are recorded. (IE add or subtract to set the sample back to 80 hex as a center point). I wrote this after I found pops and clicks while pasting audio samples into sections of silence in USS8. ------------------------------ Date: Thu, 29 Jul 93 4:58:16 EDT From: Phat H Tran Subject: SDK questions Message-ID: <9307290858.AA24596@sciborg.uwaterloo.ca> > Date: Wed, 28 Jul 1993 12:11:07 -0700 (PDT) > From: roberts@brahms.amd.com (Dave Roberts) > Subject: SDK Doc Questions still > Message-ID: <9307281911.AA10717@angelo.amd.com> > [...] I was also waiting for a reply to your message as well to see if what I've internalized about the GUS after reading the SDK doc is close to reality. But since no one has replied, I'll give you my version of the answers to your questions and hope people will correct me where I'm wrong. :) > Question #1: > > How does looping work? Specifically, how does reverse looping > operate? What are the end points? What are all the various looping > options? The docs mention resetting end points to deal with sampled > decays. What are the exact steps involved with this? How do you > handle decay without using a sampled decay? Just a volume ramp down > until you get to zero and then shut off the voice? > On the most basic of levels, a voice can play a sample with three points: the sample begin point, the loop start point, and the loop end point. |-----------------|--------------| Begin Start End --> direction of voice travel These points are all absolute addresses in the GUS' DRAM, not table offsets. You would store the Begin address in registers 0Ah & 0Bh (these hold the current address of the voice), the loop Start address in registers 02h & 03h, and the loop End address in registers 04h & 05h. Once the appropriate bits are set and cleared in the control register, the voice will start advancing in the direction shown. Note that the registers used to hold the Begin address (0Ah & 0Bh) will get updated as the voice moves, so they must be restored if you want to restart the voice. Once the voice hits the End address, the address in registers 02h & 03h will be loaded into registers (0Ah & 0Bh), thereby repositioning the voice at the Start address, and the voice will continue advancing from that point. This repeats for as long as looping is enabled. For note-off, a volume ramp to zero can be used to synthesize a decay. You can also implement a sampled decay. Consider the following sample uploaded to the GUS: |-----------------|-------------|----------------| Begin Start End Decay End --> direction of voice travel The Begin, Start, and End address are all stored in the same registers as in the previous case. Starting the voice (with looping enabled) through the control register is also done in the same manner as before. The difference is that for note-off, instead of implementing a volume ramp, looping is first disabled, and then the Decay End address is stored in registers 04h & 05h (which used to hold the loop End address). That way, instead of looping the segment between Start and End, the voice wanders off into the sampled decay, and stops once it hits the end. Reverse looping is identical except that the sample points are flipped around and the Starting Address and Ending Address registers swap roles (I think). Anyway, there's not much use that I can see in reverse looping. Bidirectional looping, OTOH, can be useful. Same concepts as above, but instead of snapping back to Start once it hits End, the voice just reverses direction. It reverses direction again once it hits Start, and so on. > > Question #2: > > The voice control registers have bits that can be modified at any time > by the GF1. The GF1 does a read-modify-write cycle to update these > bits. The SDK docs say that when writing to a register containing one > of these bits that the software should write the value twice, > separated by a delay (which is specified by I don't remember). Anyway, > this is all fine and dandy, but imagine this situation. > > Voice control reigster, bit 6, controls the direction of movement > through the wave. What if I (the program) want to update a bit in the > register. I read the register value, modify the bit I want, and write > it back twice. What if the GF1, between the program's writes changes > the direction of movement bit (because it was set to a loop mode and > hit the end of the loop points and is now bouncing back the other > way)? The problem that I see is that I (the program) will end up > setting the direction of movement bit back to the old value, which > will start the wave back bouncing the other way before it reaches the > other loop point. Am I right with this, or do I not understand > looping? Is this a problem? Is there a workaround other than, "don't > do that"? > Good question! Here's a possible solution: Before the second write, read the register again and note what state bit 6 is in and set bit 6 of the byte that you're re-writing to the control register to the same state. The reread must take place after the delay. That way, if bit 6 changes during the access period, its new state will be reflected in the second write to the register. The GUS occasionally squawks, so I think that its current drivers are corrupting some of its self-modifying bits. Perhaps a read before the second write to protect sensitive bits will get rid of these squawks? > Question #3: > > One page 4 of the SDK docs they are describing volume ramping. There > is a table that describes the rate bits. The table mentions something > called a "FUR". What's a FUR? > Just an adhoc term defined for the formulae on that page, I presume. > Question #4: > > What is the centerpoint for unsigned waveforms, 7F or 80 (hex)? > I think it could be either. But the GUS uses signed data internally, and when it converts 7Fh to signed form (by inverting bit 7 during the DMA transfer), it comes up with -1. OTOH, converting 80h to its signed form by the GUS' method yields 0. Therefore, use 80h as the centrepoint for your unsigned data. > Thanks for any help you gurus might be able to give. > You're welcome. I hope I haven't made any serious mistakes. I'm not really a programmer, nor an engineer, but a biochem student, so you're taking your chances with my "help". :) Phat. ------------------------------ Date: Thu, 29 Jul 1993 15:11:01 -0600 (CDT) From: ddebry@grue.dsd.ES.COM (Dave DeBry) Subject: WARNING: Lists running blind for a week... Message-ID: <9307292111.AA06617@grue> [This message is being sent to all the lists I maintain. If you are multiple lists, you're going to get multiple copies. Live with it.] I'm going to be out of town (at SIGGRAPH, actually... if you are going, let me know... it would be nice to meet some of you) and away from the mailing lists until August 9th. You folks are all big grown-up list users now, so Mom and I decided it's okay to leave you alone for the week. (Now watch us get hauled off to jail like that couple from Chicago. :) The emergency numbers are by the phone, there's a lot of food in the pantry... If any trouble comes up, deal with it. If anything REAL bad comes up, mail to postmaster@dsd.es.com. This is only in the worst case scenario though; their solution will be to just shut all the lists down until I get back (and then I might not be allowed to turn them back on). Have fun while I'm gone. You can have friends over, but no big parties. Ahem... Mike? Yes, you. Mr. Biesele. Pay attention. (Inside joke. Most of you can just ignore it.) -- Dave ddebry@ debry@ \ DeBry dsd. peruvian. | "All right! I admit it! I wash my socks in es. cs.utah. | club soda so my feet will fizz!" com edu / ------------------------------ End of GUS Programmer's Digest V2 #31 ************************************* 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.)