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


GUS Musician's Digest       Tue, 7 Dec 93  2:30          Volume 3: Issue   7  

Today's Topics:
    Custom patches shipped with songs (was Patch Banking Treatise)
                     GUS grannies and their banks
                     GUS Musician's Digest V3 #4
                     GUS Musician's Digest V3 #6
                             MIDI-Through
                   patch banking experiment report
                   Patch banking standards proposal

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: Mon, 6 Dec 93 09:14:29 EST
From: "Burns Fisher, VMS Engineering  06-Dec-1993 0914" <fisher@skylab.enet.dec.com>
Subject: Custom patches shipped with songs (was Patch Banking Treatise)



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

Date: 07 Dec 1993 03:40:14 +0700 (SST)
From: TC <SH7126146@NTUVAX.NTU.AC.SG>
Subject: GUS grannies and their banks

Eric,
 
> Here's the trouble with this approach. The application programs would
> have to be modified to 'know' about and handle the .cfg file. Or the
> driver would have to do the work, except the driver doesn't know
> anything about filenames you might be playing. Even if it were 'told'
> explicitly to load a .cfg file, that still means the calling
> applications have to be modified.
 
What you could do in terms of automating the process for GUS grannies,
is this: When you detect any bank switching code in the MIDI file, you
inform the user that such-and-such bank will be used for a new
instrument xxx (which could be embedded as a SysEx command). The user
can elect to have the application overwrite his ULTRASND.INI to install
the instruments in the specified banks, or install the instruments in a
new bank (of his choosing) and change all references in the MIDI file
accordingly, or ignore it.
 
Only GUS aware apps will do this of course. After all, even users of
real synthesizers have to fiddle around too.
 
 tc

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

Date: Sun, 5 Dec 1993 00:58:53 -0500
From: jericho!gord (Gord Wait S-MOS Systems Vancouver Design Center)
Subject: Re: GUS Musician's Digest V3 #4

RE: custom patches with midi songs..
I think it would be a good thing to be able to ship songs out 
and include custom patches with them. You can do this now for 
playmidi can't you? IE for a midi file named woof.mid have a
patch config file called woof.cfg that maps in the custom
 pat files? I haven't tried this for a while. It also doesn't
help under windows of course..

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

Date: Mon, 6 Dec 1993 12:55:43 -0500 (EST)
From: Phat H Tran <ptran@sciborg.uwaterloo.ca>
Subject: Re: GUS Musician's Digest V3 #6

> Date: 05 Dec 93 17:21:32 EST
> From: "Eric Bell, Howling Dog Systems" <71333.2166@CompuServe.COM>
> Subject: Bank stuff
> 
> Phat writes:
> 
> > 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.
> 
> This would make more sense, but there is no memory management in the chip at present. This task might be impossible.
>

All the memory management is done by the driver, so it can fill memory
however it wants.
 
> > 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.
> 
> I think this would give us a really excellent and flexible system, but I worry
> about having enough RAM on the board to make use of it to any extent.

I don't think RAM is any more a concern with patch banking than without.
Even if we can pick and choose patches from any bank we want for each
channel, are we likely to require any more patches than if we weren't
allowed to switch banks?  I don't think so.  I think patch usage per MIDI
piece would remain in the 20 to 30 instrument range, which 1 MB can 
accomodate very well.

Phat.

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

Date: 6 Dec 93 17:44:17 +0100
From: "Alexander Majarek, Sascha, SAM"  <Alexander.Majarek@uibk.ac.at>
Subject: MIDI-Through

Thanks again for your replies concerning my questions two weeks ago
(Midi-In, Midi-Volume, Midi-Out, etc. with a digital piano). They
helped me with a lot of problems.

One question is remaining: I am sure I have selected MIDI-Through in
PatchMan and have selected the patch in the right window. Anyway:
 ... I get NO sound when I play on my keyboard (and it sends on
CHANNEL 1 !). When I close PatchMan and start Midi-Mon or Winjammer,
I have no problems getting sound out of my gus when I'm touching my
keyboard (the patch which was selected when I closed PatchMan).

Any idea what's going wrong there (in PatchMan)

Thanks in advance,
SAM

*********************************************************************
*Alexander.Majarek@uibk.ac.at * There are 3 ways (fast, sweet, sure)*
*Perthalerg. 1c/11            * for a man to ruin himself:          *
*A-6020 Innsbruck             * 1. Gamblin'   (fast),               *
*AUSTRIA (EUROPE)             * 2. Women      (sweet) &             *
*Tel.: 0043-512-84-26-15      * 3. Computers  (sure)                *
*********************************************************************

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

Date: Mon, 6 Dec 93 10:51:20 +0100
From: f93-maj@nada.kth.se
Subject: patch banking experiment report

This is what the Borland C++ 3.1 Multimedia Reference sais about Patch Caching:
 ------------------------------------------------------------------------------

midiOutCachePatches

Syntax: UINT midiOutCachePatches(hMidiOut, wBank, lpPatchArray, wFlags)

This function requests that an internal MIDI synthesizer device preload a specified set of patches. Some synthesizers are not 
capable of keeping all patches loaded simultaneously and must load data from disk when they receive MIDI program change 
messages. Caching patches ensures specified patches are immediately available.

Parameters

HMIDIOUT hMidiOut
Specifies a handle to the opened MIDI output device. This device must be an internal MIDI synthesizer.

UINT wBank
Specifies which bank of patches should be used. To specify caching of the default patch bank, set this parameter to zero.

LPPATCHARRAY lpPatchArray
Specifies a pointer to a PATCHARRAY array indicating the patches to be cached or uncached.

UINT wFlags
Specifies options for the cache operation. Only one of the following flags can be specified:

MIDI_CACHE_ALL
Cache all of the specified patches. If they can't all be cached, cache none, clear the PATCHARRAY array, and return 
MMSYSERR_NOMEM.

MIDI_CACHE_BESTFIT
Cache all of the specified patches. If all patches can't be cached, cache as many patches as possible, change the 
PATCHARRAY array to reflect which patches were cached, and return MMSYSERR_NOMEM.

MIDI_CACHE_QUERY
Change the PATCHARRAY array to indicate which patches are currently cached.

MIDI_UNCACHE
Uncache the specified patches and clear the PATCHARRAY array.

Return Value
Returns zero if the function was successful. Otherwise, [stuff deleted]

Comments
The PATCHARRAY data type is defined as:
typedef WORD PATCHARRAY[128];
Each element of the array represents one of the 128 patches and has bits set for each of the 16 MIDI channels that use that 
particular patch. The least-significant bit represents physical channel 0; the most-significant bit represents physical channel 15 
(0x0F). For example, if patch 0 is used by physical channels 0 and 8, element 0 would be set to 0x0101.
This function only applies to internal MIDI synthesizer devices. Not all internal synthesizers support patch caching. Use the 
MIDICAPS_CACHE flag to test the dwSupport field of the MIDIOUTCAPS structure filled by midiOutGetDevCaps to see if the 
device supports patch caching.
 ------------------------------------------------------------------------------

After some experiments I have been able to draw the following conclusions:

1) When midiOutCache with MIDI_CACHE_BESTFIT or MIDI_CACHE_ALL then all
   previously loaded patches are cleared and thus incremental patch loading
   (from multiple banks, nor from a single) are not possible.

2) The Borland Reference says nowhere that previously loaded patches should be
   removed, indeed the existence of MIDI_UNCACHE and MIDI_CACHE_QUERY would
   imply the contrary.
   I do not have the (official) Microsoft spec. so I don't know for sure but
   let's hope it's just Gravis that hasn't implemented it correctly (mistakes
   can always be corrected...)

3) If a patch, that do not exist in a bank, is requested to be cached then it
   is fetched from the default bank (bank 0).

4) Say you have loaded up some patches from bank n, then MIDI_CACHE_QUERY
   will return a zero PATCHARRAY when called for all banks except bank n.
   Pathes of type 3) are also reported under bank n rather than bank 0.

5) Does anyone have any real FACTS about above?
   I think/hope that one SHOULD be able to do incremental patch caching.
   Maybe someone could contact Microsoft (who created the API) to find
   out how it should really work.

6) (To Gravis:) Does the UltraSound driver recognize any midiOutMessage
   messages? it would be fun if there where implemented a message that
   took a memory handle to a PATCHSTRUCT or something and loaded it into
   GUS memory. You could do app's that loaded any patches independently
   of ULTRASND.INI, you could do realtime patch editors et c. et c.

7) Let's hope for some order in this chaos!  3 weeks to happy GUSmas everyone!

/FMJ

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

Date: Mon, 6 Dec 1993 09:00 -0500
From: WADLEIGH@PROCESS.COM
Subject: Patch banking standards proposal

OK, let's make things as easy as possible.  There's already a patch banking 
standard in the Roland GS.  The first step should be to retain numeric 
compatibility (like the GM standard).  Now the actual implementation does NOT
have to retain the restrictions of the Roland.  In that case, switching banks
may have the undesired effect of switching previously-loaded patches (since it's
switching ROM banks).
Custom patches should be reserved for some higher bank number.  If bank #0 is
the General MIDI set and bank #1 is the GS extension set, then bank #2 is the
user's "permanent" development set and so on through bank #14.  Bank #15 is a 
"dynamic" set.  References to bank #15 would go to an external .CFG file that 
must match the file name of the MIDI file.

Did I say "simple?"  OK, so it's not easy to program and involves som new 
protocols for tracking program name and .CFG files.  Its main advantage is that 
it retains maximin compatibility with everything from Roland through PLAYMIDI.

More comments?

Hal

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

From: (null)

>We have to present a case to Gravis that will allow max flexibility with
>minimum fuss for the end user. (The granny test is a good one. It should be
>simple enough for your grandmother to get working).

Sorry, but *NOTHING* involving a PC passes this test.  MAC, maybe.  PC, no way.

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

I would think that there ought to be a much simpler scheme.  I'm thinking of MOD 
files as a model, which include the sample info directly in themselves.  One 
could do something similar if we reserved a particular bank number for this 
purpose (so there would be no conflicts with things the user did), and then if 
there were a command that one could give to the GUS driver which said something 
like "load patches into bank xxx from the following file:" and give it the path 
to the file.

But anyway, this stuff is all nice, but I'd like to see static bank switching 
implemented reasonably first (though one should probably keep the "ship a patch 
with a song" requirement in mind while designing V1 banks.

Burns

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

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

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.).



