Ultrasound Daily Digest Sun, 28 Mar 93 Volume 2 Issue 83 Today's Topics .lzh files on epas

Master Index Current Directory Index Go to SkepticTank Go to Human Rights activist Keith Henson Go to Scientology cult

Skeptic Tank!

Ultrasound Daily Digest Sun, 28 Mar 93 Volume 2 : Issue 83 Today's Topics: .lzh files on epas GMOS (2 msgs) GMOS shouldn't be needed GRAVIS & FORTE NEWS 1/4 GRAVIS & FORTE NEWS 2/4 GRAVIS & FORTE NEWS 3/4 GRAVIS & FORTE NEWS 4/4 Gus Notes and 16 bit Daughter Card and NOISE!! (2 msgs) Hi there! Proposed GMOS emulator Recording Noise Information about the UltraSound Daily Digest (such as mail addresses, request servers, ftp sites, etc., etc.) can be found at the end of the Digest. *** HEY!!! *** Before you ask a question, *** READ THE FAQ ***. It's available on the request server and the ftp sites, or check the newsgroup archives. ---------------------------------------------------------------------- Date: Sun, 28 Mar 93 00:22:39 EST From: phong%triples@Triples.Math.McGill.CA (Phong Co) Message-Id: <9303280522.AA01271@triples.math.mcgill.ca> Subject: .lzh files on epas To: Ultrasound Daily Digest Hi, I tried to download Gusmod, which is a .lzh files. I assumed that lharc.exe in /pub/pc/util would uncompressed it, but I only get a couple of files, the rest are "unknown format". What gives? Which program do I need, and where can I get it? thanks. -- Phong Co (phong@math.mcgill.ca) McGill University, Montreal, CANADA ------------------------------ Date: 27 Mar 1993 19:15:42 +0800 From: TC Message-Id: <01GWBB56619EAC48LA@NTUVAX.NTU.AC.SG> Subject: GMOS To: Ultrasound Daily Digest > Because my external synth is a D-110. Only vaguely GMish patch > mapping, and not enough voices, and those it has are LA synthesis Ok. > you have is a GUS? The question is, how many games etc which claim to > support GM support it via either the GUS MIDI port or an SBOS-emulated > SB MIDI port? (The last two may conceivably be the same from a They are the same thing (ie SB's MIDI port and the GUS MIDI port). In fact, they are the same as the MPU401 port. Only different being that the MPU401 (in smart mode) is intelligent and will return values to the calling program. These days, the MPU401 smart mode is being dropped because of the fact that a great number of people own SBs these days. Most games do dumb MIDI output now. > program's point of view). My guess is that if a game says it supports > GM, it probably expects to see an MPU-401. It may use it in dumb > mode; it may not. If it uses it in dumb mode, it *may* be enough to > simply point the game at the GUS's MIDI address, but I don't know that The GUS midi address is precisely where SB's midi address is. As for dumb mode vs smart mode. It *IS* possible to emulate the MPU401 in software. I have seen such drivers. And hence, it should also pose no problems to the proposed GMOS. Thing is, one thing at a time, so there should be dumb mode support first. Once we can get the thing dancing, there shouldn't be much more problems adding other stuff :) > worth of patches. Then the MIDI Mapper's GUS1024 map will map all the > GM patches into this 1-meg worth of stuff. That's a workaround for > non-patch-caching Windows apps, but it is also a start on how to do the > patches in GMOS. Yes, as has been suggested in several posts. We could do make GMOS load the 1MB patch set as default, load patches dynamically in the event the patch is not in memory and provide a smart mode where all patch changes will be noted and saved in a .CFG file for that particular application. This way, we can make things easier. .tc ------------------------------ Date: Sat, 27 Mar 1993 08:19:32 -0800 From: Eric N. Liao Message-Id: <199303271619.AA16654@aerospace.aero.org> Subject: GMOS To: Ultrasound Daily Digest Okay, someone asked what GMOS is. I'm not a MIDI "guru" per se, but GMOS is the term dubbed for our "GENERAL MIDI" emulator. The goal of GMOS is to allow "general MIDI" setting on many newer games (X-Wing, SQV, KQVI, etc.) to produce much better music than SBOS. About the person who pre-loaded patches manually and then ran X-Wing with "General MIDI"... How is that possible?!? The patch format for the GUS is a SOFTWARE, not hardware standard. That is, the PLAYMIDI program and Win3.1 drivers interpret all the note data, vibrato, base frequency, etc. There is nothing on the GUS baord itself to do that. The 6850 UART only receives, sends, and "pass-through" midi commands, is that right? Anyway, next time I run X-Wing, I will try the MPU-401 setting. Also, I found that John Smith's solution to game slowdown during digitized sfx works perfectly. You have to shut off music, and then (at least for me) there is no longer that slowdown associated with firing lasers. I'm not sure why so many people are blaming Lucasarts...seems more like a problem with Creative Labs to me. Look, the SB1.5 actually DROPPED the on/board CMS stereo chips (buy them separately for $30.) Like they really cost that much. This gives you an idea of Creative Labs' early products. ------------------------------ Date: 27 Mar 1993 14:21:52 -0400 From: DODSON@ac.dal.ca Message-Id: <01GWAZX49EGY00298X@AC.DAL.CA> Subject: GMOS shouldn't be needed To: Ultrasound Daily Digest Hi I am a "sometimes programmer" so I enjoy the occasional programming challenge as much as the next guy. And I've made programs before that are of limited use. It is still fun, but in this case I don't think I'll take part: It seems to me, that we are talking about compromising sound quality to fit all patches into 1meg, or else compromising performance/memory by having to access a ram- or hard- disk to get the patches as we need them. Now, it seems to me that it would be _so_ much simpler for the game companies to have a separate midi map for the 1meg ultrasound, if needed. I mean, when you install a Sierra game, it translates the music files into FM or MIDI instruments. It would be no problem at all to have a third "Small MIDI" setup, where instead of having, say CHURCH Organ, ROCK Organ, both Synth Strings, and Several other "near" patches, they just used, say Church Organ, Synth Strings 1, etc. (maybe these are bad examples; I didn't double-check) Then it would only be a matter of having the GMOS or whatever load this 1 meg worth before it loads the game, via a .gmc config file. Actually it doesn't even require the cooperation of the conpanies. I am sure there are more than a few hackers out there, who could decipher the GM instructions in games, and make a "patch" for such games to remap the whole game to 1meg worth of patches. See, this way you would lose the subtle difference between a few sounds, but if it is done right, you would keep the same "mood." Meanwhile, trying to fit all of the GM set into 1meg will result in lower quality. Also, as far as dynamic patch loading goes, this would take some pretty smart coding, or else how would the GMOS know which patches to clear to make room for the new patches. The one used least frequently? The largest one? Some kind of "read ahead" to see what will be needed? (This last one would be nice, but since GM info is usually send in "real time" it would be no good. So really the only solution to the GMOS problem, as I see it, is to go directly to the source and fix it there, using human ears to decide what sounds right, instead of leaving it up to some arbitrary algorithm or an inferior patch set. Bruce. ------------------------------ Date: Fri, 26 Mar 93 17:21:11 From: john.smith@gravis.com Message-Id: <9303261721.A5462wk@gravis.com> Subject: GRAVIS & FORTE NEWS 1/4 To: Ultrasound Daily Digest Gravis and Forte Notes ---------------------- Note: This document assumes that you installed the software in c:\ultrasnd. If you put it elsewhere, substitute the appropriate path. =================================================== WINDOWS =================================================== At least one major problem people have been having with the new release has been solved. Many thanks to Fransisco Perez. He noticed that he had a grvsultr.386 file in his \windows directory and it was NOT the new one. Apparently, windows looks in the path and uses the first one that it finds. It should have gotten the one in the windows\system directory. Using the old one with the new patches etc. causes SERIOUS problems. The old install software required the user to copy some things manually and some people put the files in the windows directory instead of the windows\system directory. The new install will install windows automatically and puts the files in the windows\system directory. To correct the problem, make sure the following files are in your windows\system and ultrasnd\windows directory ONLY!!! If you find them anywhere else, you should remove them.... windows\system: grvsultr.386 < midimap.cfg < These files are also located ultmport.drv < in the UltraSnd\Windows ultrasnd.drv < ultrasnd: ultrasnd.ini ultrasnd\windows: ultrasnd.ini oemsetup.inf mixer.exe patchmgr.exe patchmgr.hlp ultrahlp.hlp Some of you have been trying to re-run the automatic Windows install simply by running WINGUS from your UltraSound\Windows directory. The problem with this is WINGUS is looking for an install script file that has an extension of .INF. The first file it encounters is OEMSETUP.INF, which it trys to execute but because this is NOT a script file you will get MANY error messages. Try renaming OEMSETUP.INF to OEM.TMP then run WINGUS. WINGUS will then see WIN.INF and load that instead. =================================================== SBOS =================================================== INSTALLATION ============ It looks like a lot of the problems are incorrect installations. Make sure that you put ALL the correct files in the /ultrasnd/sbos directory and remove any old ones. Sbosdrv.exe , Loadsbos.exe and Sboslib.sbs MUST all be from the same release revision. They are NOT mixable. A lot of the problems you are seeing could happen if the wrong driver is used with the new loader and patch library. To make sure you are using the correct files, delete ALL files from /ultrasnd/sbos. Then unzip the new release into the sbos directory. Then COPY sbosdrv.exe up to the /ultrasnd directory. Then COPY loadsbos.exe up to the /ultrasnd directory also. Now pick either sboslo.bat or sboshi.bat up to /ultrasnd/sbos.bat. These two batch files assume you are using emm386. If you are using another memory manager (like qemm, 386max etc), use the appropriate command to load it into high memory. (NOTE: If you installed your software in some other directory, substitute it in place of /ultrasnd). Hardware ======== I know that a lot of people have said that its OK to put both a GUS and SB in the same machine. I also know that some people have had some success doing just that. However, it is really not a good idea. There are some very solid hardware reasons NOT to do this. Even though you can move the I/O address and IRQ that SBOS uses so that it will not conflict with the SB, you cannot move the DMA channel. SBOS and the SB both use DMA channel 1. Some serious bus contention happens when both cards are installed. If you doubt that this is happening, try the diagnostics in the new setup program. (You will get this in the official release soon). The DMA channel test will fail intermittantly with an SB installed. Anyway, when you are trying to get a game running, why not eliminate (Continued to next message) --- ~ QMPro 1.01 05-8925 ~ -={ Gravis UltraSound - The Power of PC Sound }=- ------------------------------ Date: Fri, 26 Mar 93 17:21:13 From: john.smith@gravis.com Message-Id: <9303261721.A5463wk@gravis.com> Subject: GRAVIS & FORTE NEWS 2/4 To: Ultrasound Daily Digest (Continued from previous message) any possible conflict? After you get the game running and you still want to try it, install it then. If the game dies now, its pretty obvious what the problem is. The 'sharing' of the DMA channel is why you will NOT get digitized output from both boards at the same time. FM stuff tends to work OK if the application used the Adlib ports (388 and 389) instead of the SB ports (22A,22C etc).Again, this is NOT recommended!!!! Another thing to check is your CMOS parameters. A lot of BIOS now let you tinker with a lot of hardware parameters. Many of the things you can change effect the timing specifications of your machine. It is quite possible to set the parameters such that the timing specs are violated. The GUS is engineered such that it conforms to a bus timing standard. The standard says the bus should run at 8Mhz. Many machines allow you to set this MUCH higher. The machine itself may function, but many peripherals (such as the GUS) may not. If you have some flakey problems (lockups, parity problems, resets etc), try setting the parameters back to the factory defaults. It would probably be a good idea to do this even if you don't think you have changed any parameters, just to be safe. Make sure that your BIOS has RAM PARITY enabled. SBOS will not function if this is disabled. If yours is disabled, make sure you have the memory chips for the extra parity bit BEFORE you enable it. Make sure there are no hardware conflicts with the I/O address, IRQ or DMA channel. If there are, you MUST resolve them or else the GUS will not behave properly. The new setup program should help diagnose these problems. When initially getting the GUS to work, we suggest removing all 'extra' hardware from your machine until you get it running. Things like other sound cards, network cards, scanner cards and printer cards are common causes of conflicts. IRQ 7 is allowed as a selection for SBOS, but it is not recommended. This is used for LPT1 and, on many machines, IRQ7 seems to be generated relatively randomly. It acts a lot like a spurious interrupt. This can cause digital sounds to terminate early since the application will think it has gotten a legitimate IRQ from the SB card saying that the DMA transfer has completed. The same thing could happen on other IRQ's if there is a conflict with another piece of hardware. IRQ 15 tends to exhibit this same phenomena. If these IRQ's (7 and 15) are not used by another device, it is GENERALLY OK to use them for the GF1 (ultrasound) IRQ. GUS software is more tolerant of getting an IRQ it doesn't expect than is SB software. Note: An Adaptec disk controller has a conflict with the default settings of the GUS. Contact Gravis for more specifics on how to remove the conflict. Usually, just moving the Ultrasound IRQ to 15 will solve the problem. SOFTWARE ======== Not all of the tips below apply to all games. This is just a brief summary of some of the things we had to do to get some games running properly. 1) Make sure the BLASTER environment string tracks our ULTRASND string. Many games look at BLASTER to set up their stuff. SBOS needs ULTRASND. If they are not the same, the game will be looking one place and SBOS will using another. This is another reason NOT to have an SB and GUS in the same system. Presumably, the SB would want BLASTER set up for it and any game looking at it would not work with SBOS. BLASTER is set up like this: BLASTER=A220 I5 D1 T1 | | | | | | | - Type of SB (1 = regular SB) | | ----- DMA channel (MUST be 1) | -------- IRQ used. (same as GUS midi irq) ------------- I/O base address This variable is set up by the GUS setup program. It should never need to be modified unless you modify ULTRASND by hand. For example, wolf3d looks at BLASTER to get its parameters. Sound will NOT function if the IRQs are different, but it will detect an Adlib. 2) Make sure that SBOS is up and running BEFORE you install your game. Some games configure themselves during their installation procedure. If SBOS is not running, it will assume there is no sound board present. 3) Some games have a separate setup/configuration section. Make sure you run this after you install the game OR change the ULTRASND variable. They are usually called setup, install or config. Look around for it. Some games also save the last (Continued to next message) --- ~ QMPro 1.01 05-8925 ~ -={ Gravis UltraSound - The Power of PC Sound }=- ------------------------------ Date: Fri, 26 Mar 93 17:21:14 From: john.smith@gravis.com Message-Id: <9303261721.A5464wk@gravis.com> Subject: GRAVIS & FORTE NEWS 3/4 To: Ultrasound Daily Digest (Continued from previous message) configuration to use the next time the game is run. This means that if it didn't detect the card (because SBOS wasn't loaded), it will save that info and will start up the NEXT time with sound disabled. You will have to manually turn sound back on somehow. See your games manual. For example, Wolf-3d will do this. 4) Some games need all available RAM to run. Since SBOS currently takes approximately 19K, it may not have enough to run. Some games will shut off some of the sounds if RAM is short. Check your manual. It may also be necessary to load SBOS high to reclaim some of the RAM. 5) If you have poor performance with SBOS loaded, see if you have an expanded memory manager running. (qemm, 386max, emm386 etc) There is a SEVERE performance penalty to be paid if you run with these. Its a byproduct of your machine running in protected mode. Usually, only games that use direct I/O (mod players for example) are seriously effected by this. If you must have SBOS loaded high, then you will have to live with this. It is possible to disable the virtual DMA if you are using qemm. (NOVDS) Doing so should speed things up a bit. 6) It is possible for an application to detect the Adlib side of the GUS without SBOS being loaded. It depends on the method it uses to detect it. Obviously if that happens, the application will think it has an Adlib, but nothing is going to work. 7) Many games need to detect (and use) extended/expanded RAM before some sounds will be activated (usually digitized stuff) Refer to your manual for these kind of problems. An SB will not operate properly under these conditions either. For example, Falcon III will not play digitized sounds until EMS is set up properly. SBOS has nothing to do with this problem. 8) Some games hard code their I/O address and/or irq selections. Refer to your manual. You will have to make the GUS' selections match these. I believe some Sierra games do this. Wing Commander requires a base port of address of 220 for digital speech to work. 9) Unless you are POSITIVE that a particular game needs an option, (-o1 -o2 etc) DON'T specify one, 99% of the games do NOT need one. You may screw up the driver by specifying one that you don't need. You should unload and reload the driver before specifying an option. Since it is possible to use more than one option, you may be telling it conflicting things if you don't unload it. 10) There are several new features in SBOS that you should be aware of, 1) SBOS reloads its patches before an application runs. This should eliminate having to reload it between running windows or a native GUS application (GUSMOD Star Con II, playmidi etc) and a game that uses SBOS. 2) You can change the vector that it uses for communicating between sbosdrv.exe and loadsbos.exe. The option is -Cxx, where xx is the new software vector to use. This is specified to sbosdrv. Currently, only 1 application is known to need this. Netroom uses the default vector (7E) so sbosdrv thinks it is already loaded. If you are using netroom, you MUST change the vector #. Netroom is the only application that we know of that has this problem. There may be others. We don't know of ANY games that do. 3) You can tell SBOS to leave line-in enabled by specifying a -L when SBOS is loaded. This can be useful if you want to monitor some other audio output source thru the GUS. 11) The volume up and down keys (defaults are [ and ]) do not work in all games. Any game that takes over the keyboard vectors will disable this feature. You must use the -V option when loading sbos to alter the volume for these games. This option works like this: -vxx where xx ranges from 0 to 31 (31 being max volume) Note: in SOME versions prior to 1.4B2, hitting the volume keys would hang your system. This has been fixed. 13) Some games grab all possible SB irqs (2,5 and 7) when they initialize to find what IRQ the SB is on. If they do this with SBOS and SBOS happens to have the UltraSound IRQ on one of the SB irqs, it will not let SBOS get its irq. Make sure that you set the UltraSound irq to one of the upper ones (Continued to next message) --- ~ QMPro 1.01 05-8925 ~ -={ Gravis UltraSound - The Power of PC Sound }=- ------------------------------ Date: Fri, 26 Mar 93 17:21:16 From: john.smith@gravis.com Message-Id: <9303261721.A5465wk@gravis.com> Subject: GRAVIS & FORTE NEWS 4/4 To: Ultrasound Daily Digest (Continued from previous message) (11,12 or 15). Jill of the Jungle is an example of a game that exhibits this problem. 14) Now for some simple things to look for. a) Is board seated properly? b) Is DRAM in sockets correctly (bent pins etc)? c) Are stereo/speakers hooked up properly? d) Are you connected to the right outputs on GUS? (Some Ultrasound boxes are labeled wrong ...) TOP OF ULTRASND =============== Amplified Out Line Out Joystick/Midi 15 pin connector Microphone In Line In BOTTOM OF ULTRASND ================== e) Do you have enough environment space for ULTRASND and BLASTER variables? f) Did you set the volume too low? g) Is \ultrasnd in your path? h) Could you have gotten a bad download of new SBOS? 15) Several people have complained about sbos loading VERY slowly. Is your joystick or MIDI plugged in? Try unplugging it. As of now, we haven't been able to reproduce this problem. It may be related to installing the software incorrectly or a DMA conflict. 16) If your joystick doesn't operate properly in a game, look for these things. a) Has it been calibrated (see manual) b) Do you have 2 games ports in your system? (GUS and another game port). If so, one MUST be disabled. c) DO you have a line like the following in you autoexec joycomp 20 where 20 is the compensation factor determined thru the calibration utility, ultrajoy. 17) There are several things people have noticed that seem to effect SBOS that need to be investigated. None of these have been verified, but you should be aware of them and you might try eliminating them as possible sources of your problem. 1) Loading SBOS hi can cause some FM stuff to sound 'weird' 2) Using 'Stealth' mode on QEMM seems to have a detrimental effect. 3) Change sbos.bat file to use loadhi instead of lh if using QEMM. 4) Stacker seems to cause some people problems. It works OK for others. 5) Order that TSR's are loaded may have an effect. Try loading SBOS first, last etc. 6) When using XWing make sure that you have at least 896K of EMS (not XMS) and 563K of conventional. If you are having problems with slowdowns try turning off the music. 19) The only other thing we can think of is a hardware problem on your card. The diagnostics in the new setup program should be able to isolate it. Granted, we are a bit biased, but we believe that you should get SUPERB sound out of your GUS. If you are getting less than satisfactory results, there can only be a few explanations. 1) in windows, make sure its in 'high fidelity' mode 2) Incorrect software installation. 3) Incorrect hardware installation (IRQ,DMA etc) (probably) 4) Bad hardware. (PC or GUS) 5) Being overly critical of a $150 sound card..... John & Pete --- ~ QMPro 1.01 05-8925 ~ -={ Gravis UltraSound - The Power of PC Sound }=- ------------------------------ Date: Sat, 27 Mar 1993 14:44:24 -0500 From: "Loking... Searching" Message-Id: <93Mar27.144430est.247217-2@descartes.uwaterloo.ca> Subject: Gus Notes and 16 bit Daughter Card and NOISE!! To: Ultrasound Daily Digest   ------------------------------ Date: Sat, 27 Mar 1993 14:46:13 -0500 From: "Loking... Searching" Message-Id: <93Mar27.144616est.247239-1@descartes.uwaterloo.ca> Subject: Gus Notes and 16 bit Daughter Card and NOISE!! To: Ultrasound Daily Digest >19) The only other thing we can think of is a hardware problem > on your card. The diagnostics in the new setup program should > be able to isolate it. > >Granted, we are a bit biased, but we believe that you should >get SUPERB sound out of your GUS. If you are getting less than >satisfactory results, there can only be a few explanations. > 1) in windows, make sure its in 'high fidelity' mode > 2) Incorrect software installation. > 3) Incorrect hardware installation (IRQ,DMA etc) (probably) > 4) Bad hardware. (PC or GUS) > 5) Being overly critical of a $150 sound card..... > >John & Pete > ~ QMPro 1.01 05-8925 ~ -={ Gravis UltraSound - The Power of PC Sound My reaction to this note , is that I am surprised to see that even your answer suggests that you have doubts with your product. " Being overly critical of a $150 sound card.... " Is a bad comment to make if you want to sell your product.. it puts doubts in my mind about the card, Although I am a satisfied customer of the gus. Another question regarding sound quality, I've read some where, I believe from Phat, that the GUS is one of the most "quietest" sound cards out there. Now, i f I get the 16 bit record daughterboard, which I would like to very much, will t he samples come (%5 tolerance at the most! ) to CD quality.. I know this is adv ertise as so. But the fact is. that There is noise! I'd like also to know the final answer to the question of why there is noise when recording a NULL signal... and the solution. Also if I do get the Daughterboard will that come with software? like any type of patch / sample editor for 16 bit samples. Will this daughterboard elminate the 'clicks' between (I think) 256k (whatever t he interval is) intervals in a long sample? Or this this a software problem ( not enough buffering?) ------------------------------------------------------------------------- Mark C. Ng mcng@undergrad.math.uwaterloo.ca University of Waterloo Sysop of Digital Pixel BBS:(416) 298-1487 Toronto,Ontario,Canada,Sol System >COMGFXMIDISDINOSAURSEJAPANESEXBADMINTONYANIMEGBIKEIPURPOSEROFLLIFESARTS< ------------------------------------------------------------------------- ------------------------------ Date: Sat, 27 Mar 1993 13:56:20 +0100 (MET) From: roy@ulke.dhmolde.no (Roy Magne Indreboe) Message-Id: <9303271256.AA17762@ulke.dhmolde.no> Subject: Hi there! To: Ultrasound Daily Digest Please add me to the list! Thanks. ------------------------------------------------------------------------------ Name : Roy Magne Indreboe e-mail: roy@ulke.dhmolde.no s-mail: Solliveien 45, 6400 MOLDE, NORWAY ------------------------------------------------------------------------------ Silence speaks so much louder than words - Pink Floyd ------------------------------------------------------------------------------ ------------------------------ Date: Sun, 28 Mar 93 03:18:52 +0300 From: ahti@win.goodwin.ee (Ahti Heinla) Message-Id: <7A99.1A7C1A5A@win.goodwin.ee> Subject: Proposed GMOS emulator To: Ultrasound Daily Digest about the gmos project: instead of dynamic patch loading, someone proposed to load all 192 gm patches to gus memory, so that there would be no need to load patches in real-time. i'd like to mention that there is actually no need to load all 192 patches; many gm patches sound roughly the same and the whole gm patch map can be implemented with 30..80 patches, i think. this way, the overall sound quality can be better and so would the final result, i believe. ahti ------------------------------ Date: Sat, 27 Mar 1993 17:17:23 +0800 (WST) From: rlee@tartarus.uwa.edu.au (Ralph Lee) Message-Id: <199303270917.AA07183@tartarus.uwa.edu.au> Subject: Recording Noise To: Ultrasound Daily Digest I know this might be a bit slow, but I've only just managed to find the time to play around with the recording capabilities of the GUS. I do have a few questions that I hope someone may be able to answer: 1) When using USS8, the sample sounds have slow downs. I assume this is to do with the HD but I'm not sure if there is a solution. There was also some background hiss off recording a CD - is that normal or is my GUS a bit stuffed??? 2) Recording using Recorder on Windows or Pocket Recorder also induces alot of background hiss even though the quality is not too bad. Can I acutally record at 44.1 in Windows???? I'm still using the old install disks as I haven't the time to download the new ones..... Thanks Ralph rlee@tartarus.uwa.edu.au ------------------------------ End of Ultrasound Daily Digest V2 #83 ****************************** Digest Address: ultrasound@dsd.es.com To post to tomorrow's digest Request Server Address: ultrasound-request@dsd.es.com To subscribe, unsubscribe, and request files Owner Address: ultrasound-owner@dsd.es.com To contact a human if the server has troubles FTP Sites: archive.epas.utoronto.ca pub/pc/ultrasound wuarchive.wustl.edu systems/msdos/ultrasound


E-Mail Fredric L. Rice / The Skeptic Tank