
GUS Musician's Digest       Fri, 29 Oct 93  3:25 MDT     Volume 1: Issue  10  

Today's Topics:
          Filters? Need 'em, gotta have 'em, can't do 'em...
                     GUS Musician's Digest V1 #9
                         GUS sound filtering
                           new piano patch
                           What we need...

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, 28 Oct 93 06:24:05 PDT
From: deraud@power.amasd.anatcp.rockwell.com (Robert Lee DeRaud)
Subject: Filters? Need 'em, gotta have 'em, can't do 'em...

>From: Steve "Bongos" Larson <larson@ee.ualberta.ca>
>Subject: Filtering? I say yay... you say nay...

>Chris said:
>>Not a chance. (Because it doesn't have enough hardware level processin power).

> -> Filtering a digital waveform is as simple as performing a discrete
>    mathematical convolution on the waveform. Of course, real digital
>    waveforms (sampled) are harder to convolve with a given impulse
>    response (the filter) than a pre-computed waveform, but nonetheless
>    the software emulation proceeds akin to OUTPUT=INPUT*FILTER. IMHO,
>    it _is_ possible to do software filtering, but alas, it is CPU
>    consuming (in real time) unless the wavetable sample is filtered
>    first, and then the result played back in real time. What does all
>    this jargon mean? It means that we should see someone taking the
>    challenge soon, and writing a package that will do just this,
>    (unless, OC, it's been done :-)

Looks good on paper, BUT...a decent filter takes 6-8 multiplies, 3-4 
adds, and a slug of memory accesses per output sample. So, for 14
voices at 44KHz (GUS output max aggregate data rate, I think), you've got
about 1.6 microseconds per sample or about 100 clock cycles at 66MHz. 
(Mind you, this TOTALLY ignores the problem of how to get the raw GUS
output data into memory and then the filtered data back to the DAC...)
I don't have a 486 instruction timing chart here at work, but it looks
like the bit from 'Jaws': "You're gonna need a bigger boat."

This is a classic case where special-purpose hardware really is better/
more cost-effective than software at the current technology level: note
that it is a non-trivial problem even with programmable DSP chips,
at least at the cost-point of the GUS.

As far as prefiltering the wavetable is concerned, this is the *problem*, 
NOT the solution: the real-time dynamics (pitch-independent filter sweeps 
etc) that give the high-end synth its "character" are missing. [Long- 
time readers will remember several previous (lengthy) posts from me on 
this subject...:-)]

***********************************************************************
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: Thu, 28 Oct 93 10:56:57 GMT
From: james@maths.exeter.ac.uk
Subject: Re: GUS Musician's Digest V1 #9

Steve "Bongos" Larson <larson@ee.ualberta.ca> wrote
>
>	--> Filtering a digital waveform is as simple as performing a discrete
>	    mathematical convolution on the waveform. Of course, real digital
>	    waveforms (sampled) are harder to convolve with a given impulse
>	    response (the filter) than a pre-computed waveform, but nonetheless
>	    the software emulation proceeds akin to OUTPUT=INPUT*FILTER. IMHO,
>	    it _is_ possible to do software filtering, but alas, it is CPU
>	    consuming (in real time) unless the wavetable sample is filtered
>	    first, and then the result played back in real time. What does all
>	    this jargon mean? It means that we should see someone taking the
>	    challenge soon, and writing a package that will do just this,
>	    (unless, OC, it's been done :-)

Of course its been done! The cool wave editor has a sort of graphic equaliser
in it, our pal sox can do band pass filtering and the registered version of
noisemaster does high pass low pass and band pass.  Cool also has nice flanging
BTW.
The snag is that most of these packages only supply a static filter ie you
set it up and it can cut out mains hum or hiss or whatever.
What is needed for voicing is a dynamically controllable filter.
Fortunately, the csound package can do this and has a huge selection of filters
( resonant, comb, vocoder ) but unfortunately its flexiblity means its a bit
tricky to set up.

-- 
James Andrews, Computer Development Officer, Exeter University Maths Dept

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

Date: Fri, 29 Oct 93 09:30:08 EST
From: David Mitchell <davidm@hparc1.aus.hp.com>
Subject: GUS sound filtering

I was hoping this might trigger a discussion...

When I suggested implementing software filtering on the GUS, I was pretty
sure that the CPU overhead would make things tough in real time.  A second
best process would be to implement the filtering "offline" - apply the
filter to the waveform, "save" the filtered waveform, then play back the
filtered waveform in real time.

This should be quite possible (after all, the process is very similar to
creating artificial reverb, flanging, etc.) and should sound interesting.

Yes, I would *love* to be able to "turn knobs" and "push sliders" onscreen and
have the changes appear in the waveform in realtime, but I'm not sure it's
possible except with a relatively low sampling rate (less samples=less
CPU required).

Of course, tomorrow it'll probably be uploaded to epas by somebody...

So now there's a multitrack recorder for the GUS that has problems with pops/
hiss/noise and uses lots of disc space (MRGUS01A.ZIP), a program to record
"jitter-free and dropout-free" stereo (GUSDELAY.ZIP), and a program to compress
recorded data that achieves 4:1 compression with little loss in sound
quality (ADPCM).  Is anybody else thinking what I'm thinking...?  That maybe
these guys should get together...

Does anyone think there'd be a market for digital multitrack recording
with stereo output, low disc space overhead, and potentially 16-bit recording
in the near future, on a $US130 soundcard?

Dave Mitchell

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

Date: Thu, 28 Oct 93 8:36:15 CDT
From: Don Eller <don.eller@inst.medtronic.com>
Subject: new piano patch

I'll have to admit, I was surprised how much better swngcafe.mid
sounds with the new piano.pat used in place of acpiano and brpiano.

I was quite disappointed when I tried striving.mid and found that it
sounded a lot worse.  Under playmidi this is not a problem since you
can have a cfg file for each song to set the best mix of patches for each
song, but under windows midi players this mechanism doesn't exist,
does it?

I haven't tried it with a lot of piano midi files yet, but I will
provide updates as I find examples of midi files where the new piano
patch sounds worse than acpiano.  I suggest that if new versions of
this patch are uploaded that a comment with version be included.

If this message comes off too critical, that's not my intent.  I
applaud your efforts and look forward to reading feedback on any new
patches submitted.

PS: Has everyone noticed the new windows jukebox player juker23 in the
epas submit directory.  It appears to be freeware, and supports patch
loading.  The only oddity is that albums can only be created by drag
and drop, so you have to use file manager to browse for midi files to
add to your albums.  It would be a nice addition to have the built-in
file browser as well.  I think this jukebox is an overall better player
than the one that comes with winjammer.

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

Date: Thu, 28 Oct 93 15:42:13 PDT
From: brian block <bblock@newservr.engr.uidaho.edu>
Subject: What we need...

I have been a GUS owner for about 3 months now and have found
the card to have very impressive musical capabilities. 
Unfortunately, I also found that this potential is not being
realized with the current software available. The following is
what I think the Ultrasound needs to become a viable semi-
professional music tool:

First, patch management under Windows is inadequate.  Having
to edit ULTRASND.INI every time you want to audition new
patches is way too cumbersome in a music production setting. 
Second, we need a way to utilize the vast assortment of
instrument patches available for existing samplers. 
Compatibility with sample patches in the AKAI S1000 series,
Esoniq EPS, and Kurzeweil formats would open up a world of
musical possibility to anyone that can't afford a $2000
sampler.  Being able to audition patches of only one format is
like having a graphics viewer that can only read one
(proprietary) file format.  Technically, I see no reason why
multiple format patch compatibility can't be done.

I'm not a programmer, but this is what I envision for an
improved Windows Patch Manager.  Instead of two windows for
patches in the MIDI set and patches loaded into RAM, there
would be three windows for:  all patches saved on disk,
patches loaded into RAM, and patches in the current MIDI set. 
Any patch on disk could then be loaded into RAM and
auditioned. Then, if desired, it could be moved to replace a
patch in the MIDI set.  
                    
Furthermore, an unlimited number of complete MIDI sets could
be saved and retrieved.  Now for the good part:  In the window
that shows all patches on disk, any of the different patch
formats mentioned above could be selected.  When moved to RAM,
these sample formats would be converted on-the-fly to GUS
format and could then be auditioned.  If moved to the MIDI
set, the patch could then be saved to disk in GUS .pat format.

Like I say, I don't have the expertise to develop this, but I
thought I'd throw it out for comment/suggestion to the people
who do have the programming know-how (Gravis, are you
listening?)

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

End of GUS Musician's Digest V1 #10
***********************************

To post to tomorrow's digest:                        <gus-music@dsd.es.com>
To (un)subscribe or get help:                <gus-music-request@dsd.es.com>
To contact a human (last resort):              <gus-music-owner@dsd.es.com>

FTP sites:                archive.epas.utoronto.ca       pub/pc/ultrasound
                          wuarchive.wustl.edu     systems/msdos/ultrasound
                          archive.orst.edu             pub/packages/gravis
FTP mail server:          mail-server@nike.rz.uni-konstanz.de

Hints:
      - Get the FAQ from the FTP sites or the request server.
      - Mail to <gus-music-request@dsd.es.com> for info about other
	GUS related mailing lists (general use, programmers, etc.).


