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 <ultrasound@dsd.es.com>

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 <SH7126146@NTUVAX.NTU.AC.SG>
Message-Id: <01GWBB56619EAC48LA@NTUVAX.NTU.AC.SG>
Subject: GMOS
To: Ultrasound Daily Digest <ultrasound@dsd.es.com>

> 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 <liaoe@aero.org>
Message-Id: <199303271619.AA16654@aerospace.aero.org>
Subject: GMOS
To: Ultrasound Daily Digest <ultrasound@dsd.es.com>

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 <ultrasound@dsd.es.com>

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 <ultrasound@dsd.es.com>

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 <ultrasound@dsd.es.com>

(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 <ultrasound@dsd.es.com>

(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 <ultrasound@dsd.es.com>

(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" <mcng@undergrad.math.uwaterloo.ca>
Message-Id: <93Mar27.144430est.247217-2@descartes.uwaterloo.ca>
Subject: Gus Notes and 16 bit Daughter Card and NOISE!!
To: Ultrasound Daily Digest <ultrasound@dsd.es.com>






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

Date: Sat, 27 Mar 1993 14:46:13 -0500
From: "Loking... Searching" <mcng@undergrad.math.uwaterloo.ca>
Message-Id: <93Mar27.144616est.247239-1@descartes.uwaterloo.ca>
Subject: Gus Notes and 16 bit Daughter Card and NOISE!!
To: Ultrasound Daily Digest <ultrasound@dsd.es.com>

>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 <ultrasound@dsd.es.com>

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 <ultrasound@dsd.es.com>

	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 <ultrasound@dsd.es.com>

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
******************************
