Apparently-To: john.smith@gravis.com


GUS Musician's Digest       Sun, 5 Dec 93  2:27          Volume 3: Issue   5  

Today's Topics:
                     GUS Musician's Digest V3 #4
                             MIDI circuit
                            Patch Banking
                   Patch banking and custom patches

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: Sat, 4 Dec 1993 16:24:40 -0600 (CST)
From: Antonio Guia <guia@CC.UManitoba.CA>
Subject: Re: GUS Musician's Digest V3 #4

to whomever posted the pin mapping for the optocoupler chips:

one more comment to add that you forgot about, the notch on the end of the
chip is usually a square cut or half-circle cut on the TOP end of the
chip, or a little dot on the TOP RIGHT corner of the chip, so that the
chip's pins are number from number 1 on the top left, increasing downward
on the left, then across to the other side and increasing upward on the
right so that the highest pin number is beside that dot, or on the top
right corner of the chip.

also worthy of noting is that usually the vcc (positive voltage) is fed to
pin 1 to supply power to the chip, and the ground for the chip is the last
pin on the top right (pin 8 in an 8-pin chip, or pin 32 in a 32-pin chip, etc)

your map along with which side is the top of the chip should probably be
included in the FAQ though.

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

Date: Sat, 4 Dec 93 22:09:34 EST
From: dulimart@cps.msu.edu (Hansye S. Dulimarta)
Subject: MIDI circuit

   Date: Thu, 02 Dec 1993 22:17:15 +0200
   From: PWRJAM01@Uctvax.UCT.AC.ZA

   Thanks to all of you who replied my questions about the midi circuit -
   there were quite a few replies...  I am in the middle of a tough battle
   with this damn circuit!

   1]  I have not connected the midi thru - see diagram (not connected)
       Check this - I presume you can do it as the current does not
       have to flow unless its connected ?

Pin-4 of MIDI THRU and +5v are connected through 220 Ohm resistor.
So do Pin-5 of MIDI THRU and pin-4 of 74LS04 (inverter).

       NO I Did NOT connect the MIDI IN's GND

This is correct.  MIDI IN's ground is not connected.

   4]  OK this is the one I am not sure about - the IC's pin numbers
       There is a little dot in the lower left hand corner of the 
       6N137 (looking at it with the 6N137 number visable) I took this
       to be pin one - the one above pin 2 - the one to the right pin 3 etc

       2 4 6 8    this method aggreed with the diagram looking from the solder
       | | | |    side.  I used the similar idea with the Inverter ( bottom
	6N137     left pin 1 )
       | | | | 
       1 3 5 7 

No. This is not how you number the pins.  You should number them in
counter clockwise direction starting from the pin with little dot.

           8  7  6  5
           __________
          |_         |
           _]        |
          |._________|
           1  2  3  4


Hans.

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

Date: Sat, 4 Dec 1993 12:47:13 -0500 (EST)
From: Phat H Tran <ptran@sciborg.uwaterloo.ca>
Subject: Patch Banking

> Date: Fri, 03 Dec 1993 12:11:50 GMT
> From: Clarke Brunt <CLARKE@lsl.co.uk>
> Subject: Patch Banking
> 
> > My sentiments exactly.  Patch caching has to be smart enough to look for
> > Controller 0 and then cache patches from the right banks, but the driver
> > would also have to respond to Controller 0 to switch banks on the fly.
>
[...] 
> To use more than one bank at once, firstly MidiOutCachePatches would
> have to keep any patches from other banks that you had already loaded
> (see my question of yesterday), and secondly, the driver would have
> to remember that it had loaded (say) patch 0 from bank 0, AND patch
> 0 from bank 1, so that it could meaningfully respond to the controller
> 0 messages and switch.

Yes!  

> Date: 03 Dec 93 09:40:59 EST
> From: "Eric Bell, Howling Dog Systems" <71333.2166@CompuServe.COM>
> Subject: Patch Banking Treatise
>
[...] 
> The Custom Patch with Song File Opportunity
>  ------------------------------------------
>
[...] 
> If I make a song up that uses three custom patches and I put them in bank 33,
> and then put it all up on the net, then you've got to install the patches
> somewhere, and the ULTRASND.INI file must be changed. What if you already have
> a bank 33 in use with some other patches in it? Then there's a problem.
> 
> I propose an application program be created that would be able to scan the
> ULTRASND.INI file and create the bank entries for the music file you are
> installing, with the correct patch names, and subdirs etc.

Adding a bank for each MIDI file that needs custom patches can become
very unwieldy, but I guess it's the best we can do with the current drivers.
Automating the bank entry editing would save a lot of hassle.  I think
this function of processing a MIDI file, adding the new bank entries, and
modifying the MIDI file to point to the appropriate bank should be 
incorporated into some sort of patch librarian (Patch Man on steroids).

> Date: 03 Dec 93 11:16:40 EST
> From: "Eric Bell, Howling Dog Systems" <71333.2166@CompuServe.COM>
> Subject: Patch stuff
> 
> Let's see if I can remember how this works. As long as you are loading
> additional patches on top of what is there, and ask for the patches that are
> already there as well as the new ones, it will do an incremental load.
> 
> However, since melody patches are loaded under drum patches, any changes to
> these, do cause the drums to be reloaded. 

Why not have the Windows driver fill GUS RAM from the bottom (0k) up
with melodic patches, and from the top (1024k -- or 1016k if 8k is 
reserved for WAV buffering) down with percussion patches?  This would
save having to reload the drum patches each time a new melodic patch
was needed.

To summary, I suppose this is what we would like to see in the Windows
driver:

1.  MidiOutCachePatches should keep previously loaded patches when called
    upon to cache new ones.  The old patches should only be dumped by an 
    explicit clear memory function (does one exist?), or if adding the
    new patches exceeds available memory (in case some apps don't bother
    to clear GUS memory before loading a new set of patches for a new
    song).

2.  MidiOutCachePatches should keep track of not only which patches have
    been cached, but from which bank.

3.  The driver should respond to Controller 0 to keep track of which bank
    is active for _each_ channel.

If the above three points are implemented, then a sequencer can scan a
MIDI file for Controller 0's and Program Changes and cache the 
appropriated patches from the appropriate banks for each channel.  Then,
as the song plays, the driver would be able to use patches from the correct 
banks.

4.  The driver should fill GUS RAM from the bottom up with melodic patches
    and from the top down with percussion patches to avoid having to
    reload the drums when a new melodic patch is cached.

Phat.

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

Date: Sat, 04 Dec 1993 13:34:42 -0500 (CDT)
From: TRIPLETT@swmed.edu
Subject: Patch banking and custom patches

In GUS Musician's Digest V3 #4, Eric Bell writes:

>First off, I think it would be cool to create MIDI music using a few custom
>patches, be the Hendrix samples, stuff from TV (ala MOD music), or specific
>instruments with particular characteristics (flugelhorn, for example for that
>Chuck Mangione piece you've been wanting to do).
>
>Is there a concensus out there that users would want to create and listen to
>MIDI music in this fashion? That you would download someones composition 
with
>a few patch files that they'd created or appropriated, all zipped up together,
>and that you could load onto your machine and play without much ado?
>
>Please squack if you think this is valuable, desirable, etc.

SQUACK, SQUACK, SQUACK, SQUACK, SQUACK !!!!!

Yes, indeed.  Since the possibility of multiple patch banks reared its head, 
I have been wondering just how things would work out in reality.  I mean, 
either we would all have to agree on a 'standard' set of patch banks that we 
would all set up on our hard drives (with the same directory structure etc.) 
so that we could all hear a composition as it was intended,
or we adopt the kind of scheme you have suggested.  The former is 
actually not a bad idea, and as I recall, has already been proposed in the 
recent past.  I think this would work best in the long run if the other patch 
banks were set up as variants of the GM set with changes appropriate for 
different styles of music (ie, a rock-n-roll set with better guitar
patches, drums, maybe a wider range of sounds in the synth and keyboard 
sections of the GM set, and so on).  Again, I think this was the essence of 
the recent suggestion.  That way, someone without the custom patch bank 
will still be able to hear something that sounds ok, when using the 
standard GUS patches, and the number of zip files bloated with extra stuff 
would stay small.
But... this does not provide for compositions with unique patches such as 
Eric described. The problem I have with the scheme he proposed is that it 
sounds pretty complicated.  Why not use an approach like the *.cfg files 
for Playmidi?  The only complication is the patch banks and how to work 
them into the scheme.  Well, it seems to me we could all agree to 
leave one or several patch banks unused that all custom stuff would 
default to.  You unzip the midi file and custom patches into whichever 
directory you want, play the file, the calling program (or the windows 
drivers) scans the directory for a *.cfg file, loads the custom patches in the 
agreed upon empty bank, any other patches come from the default GM
set, and the file plays.  Quick, painless, no editing of *.ini files, no 
scanning for bank conflicts.  Even my grandmother could figure it out 
<g>.  
So what is your opinion?  Maximum flexibility, or some agreed upon 
standard procedure that hopefully would be less complicated to use, let 
alone implement in software?
So now I will sit back and wait for the results of my first post (!). 
Bye all,
Terry (aka triplett@utsw.swmed.edu)

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

End of GUS Musician's Digest V3 #5
**********************************

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
                     theoris.rz.uni-konstanz.de                /pub/sound/gus
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.).



