From mailserv@gaia.ucs.orst.edu Wed Nov  9 14:10:34 1994
Precedence: Bulk
Date: Wed Nov  9 12:05:45 PST 1994
From: gus-music-request@gaia.ucs.orst.edu (GUS Musician's Server)
Reply-To: gus-music@gaia.ucs.orst.edu (GUS Musician's Digest)
Subject: GUS Musician's Digest V10 #8

GUS Musician's Digest       Wed, 9 Nov 94 12:05 PST      Volume 10: Issue   8 

Today's Topics:
                       Extracting samples (fwd)
              Using lots of patches with a sequencer II
             using thousands of patches with a sequencer

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: Wed, 9 Nov 1994 14:43:18 -0500 (EST)
From: "K.S. Holly" <u8843389@muss.CIS.McMaster.CA>
Subject: Extracting samples (fwd)

Sorry if this got posted twice....


I know this is old news but I've only recently gotten into making music 
with the GUS.

How can I extract samples from midi files or mod files?

Oh, and one more question. If I was not going to be doing any sampling, 
is it worth is to take advantage of the 'upgrade to the MAX' offer?

All help appreciated.

Kevin

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

Date: Wed, 9 Nov 1994 11:15:08 +0100
From: A.PAUW@ELSEVIER.nl
Subject: Using lots of patches with a sequencer II

> Perhaps if we, as users, can agree on a standard, it would be easier to persuade
I agree with that, I suggested something similar on the standard
digest some time ago.
> sequencer authors to implement the standard.  Note that the GUS driver DOES
> support bank switching, which makes it possible to select from your tons
> of patches.  It does not however implement incremental patch loading, thus
> all patches must come out of one bank (with unfound patches defaulting to
> bank 0).
> 
> Proposal:
> For tracks mapped to a GUS synthesizer port:
> 1) Bank number is determined normally by (controller 0 * 128 + controller 32),
>    i.e. CC0 is MSB, CC32 is LSB.
This is the standard MIDI bank select (Roland uses the reverse 
(controller 0 + 128 * controller 32)
> 2) Channel 10 is always treated as a drum channel.
Also standard, so no problem
> 3) (optional) User can elect if channel 16 is to be treated as a drum channel
>    (since user may map these via midimapper).
Not needed I think, let's keep it `simple'
> 4) To support files generated for GS and similar synths:
>       - If CC0 is used without CC32, it is treated as the bank number directly.
This is tricky, the latest Sound Canvas use CC32 also and, as written before, 
works reversed of what is standardized by the MIDI specs
>       - If a program change occurs on a drum channel and there are no CC0/32
>         changes on that channel, it is used as the bank number
Yep, I agree
> 5) The sequencer assumes that the first non-zero bank encountered for melodics
>    becomes the "controlling" bank, and to map this into the wBank argument of
>    the midiOutCachePatches call.  (Similar logic for drums).
I assume you mean a selection scheme as Roland's GS, which is a
little more tricky, the effect patches (seashore etc.) don't have this `fall 
back' system and are not mapped onto the primary bank.
> 
> Banks can then use the following conventions:
> Banks 0-511 can be "standardized".  Suggest using GS bank numbers where
E.g. bank 127 (Roland counts 1-128 etc., so then it would be bank 128) is 
the MT-32 mapping 
> applicable.
> Banks 512+ can be song-specific.  These might be used where necessary to
> load patches across multiple banks.
Let's call them USER banks
> 
> is defined in bank 128.  There is no way to avoid this with the present driver,
> because of unimplemented incremental patch loading.
I hope it will be implemented soon, as it is a big restriction
compared to other MIDI devices (sound modules).

Now, the thing to do would to make a `standardized' ULTRASND.INI
file, containing the banks and patches. Every bank has its own
directory. Since I don't have some many Patches more than the
standard ones, how are we going to define the other patches?
Better (other instrument patches) like piano etc. can be used in
the different banks. Thinking about it, it would be nice to have
all banks on a CD-ROM. Ok, it takes some time to load them in
the GUS, but you can keep them together and everyone has the
same patches in the same banks.

What are your thoughts about this.

Albert Pauw
a.pauw@elsevier.nl

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

Date: Tue, 8 Nov 1994 17:12:32 -0500 (EST)
From: Robert Coleman <rcoleman@gaia.ucs.orst.edu>
Subject: using thousands of patches with a sequencer

On Tue, 8 Nov -1, GUS Musician's Server wrote:
> Date: Tue, 8 Nov 94 09:33:29 EST
> From: ivan@molson.ho.att.com (Ivan Strom)
> Subject: Re: using lots of patches with a sequencer
> 
> ------------------------------
> 
> Date: Sun, 6 Nov 94 19:12:16 EST
> From: Robert Coleman <rcoleman@mail.cc.trincoll.edu>
> Subject: using lots of patches with a sequencer
> 
> I have tons of patches on my hard drive that i've made.  i'd like to be able
> to select them from inside a sequencer (using winjammer at the moment...)
> by their filenames or some other meaningful tagname that i give it.  then
> it will be easier to work inside the sequencer, since all the patch-change
> messages will show the name of the sound, rather than a number or generic
> midi name...which i find very difficult to work with.
> 
> can anyone help with this ?????
> 
> ------------------------------
> 
> I've discussed GUS bank-switching support with Dan McKee, the author of WinJammer,
> who stated he wasn't interested in adding this since there wasn't general
> agreement on how it should be done, nor a good way of doing it due to the
> limitations of the GUS driver.
> 
> Perhaps if we, as users, can agree on a standard, it would be easier to persuade
> sequencer authors to implement the standard.  Note that the GUS driver DOES
> support bank switching, which makes it possible to select from your tons
> of patches.  It does not however implement incremental patch loading, thus
> all patches must come out of one bank (with unfound patches defaulting to
> bank 0).

Hmmmm...that gets me thinking.  *My* idea of how bank select can help me
work better goes something like this:

I have a many midi songs that i make. at the top of each track is a 
bank-select, for picking the bank i created with bank-manager, 
patch-manager's counterpart, and a patch-change (if it's a non-drum bank) 
event to pick which multisample i want to play.  this ends up being so that
the sequencer can toss out the old, unused patches to make room for the 
new ones i want, seeing as how there *is* only 1 meg in there, and it has 
to be managed Somehow!!

so it seems like somehow the sequencer, or the driver, or both, have to 
anticipate somehow, else there might be a delay that throws things off. 
perhaps this isn't important just yet, but might be later......

> Proposal:
> For tracks mapped to a GUS synthesizer port:
> 1) Bank number is determined normally by (controller 0 * 128 + controller 32),
>    i.e. CC0 is MSB, CC32 is LSB.
> 2) Channel 10 is always treated as a drum channel.
> 3) (optional) User can elect if channel 16 is to be treated as a drum channel
>    (since user may map these via midimapper).
> 4) To support files generated for GS and similar synths:
>       - If CC0 is used without CC32, it is treated as the bank number directly.
>       - If a program change occurs on a drum channel and there are no CC0/32
>         changes on that channel, it is used as the bank number
> 5) The sequencer assumes that the first non-zero bank encountered for melodics
>    becomes the "controlling" bank, and to map this into the wBank argument of
>    the midiOutCachePatches call.  (Similar logic for drums).
> 
> Banks can then use the following conventions:
> Banks 0-511 can be "standardized".  Suggest using GS bank numbers where
> applicable.
> Banks 512+ can be song-specific.  These might be used where necessary to
> load patches across multiple banks.
> 
> Note a caution in the above:  If a sequence has the following:
>        Track 1: Channel 1, Bank 0, ProgCh 0
>        Track 2: Channel 2, Bank 128, ProgCh 32
> then the progch 0 will be loaded out of bank 128, not bank 0, if progch 0
> is defined in bank 128.  There is no way to avoid this with the present driver,
> because of unimplemented incremental patch loading.
> 
> 
> Any comments on this.  I've brought up this issue before (without this much
> detail) but have never generated much comment.
> 
> ------------------------------
That sounds pretty much fine...but the but about limiting drums to chs. 
10 & 16...what if i want *all* my channels to be different drum maps ???
Maybe this idea:
   letting the sequencer decide when a bank is no longer being used and 
ditch it.  it can easily tell this by going over the song from the back 
end to the front... and likewise, if a bank doesn't get used for a very
long time, during which time another bank gets called-for, then temporarily
ditching that one......the logic for this might get a bit complex and 
maybe the presumptiveness could cause a song's patches to fail loading 
when otherwise they could have succeeded thru manual control of which ones
to ditch and which ones to keep....so letting the user, thru events, also
have a hand on this would be nice.

maybe something should be thrown in, between the Gus driver , and the
sequencer, or whatever uses the patches: a kind of Patch Daemon, who has 
the smarts and so-forth to manage the Gus in the Best Possible Way.  
After all, sequencer authors can't be expected to become Master Of All 
Soundcards' Peculiar Operating Rules, now can they !!!??!!

Tell ya what, I might just be willing to write something like this, that 
is IF there was enough demand for it... and IF it could be done in plain 
old C++ (as i am a microsoft-windows virgin).. the logic and the coding 
and the memory-management techniques i can handle though!!

Now that i think about it....it would be so nice if, after issuing a 
bank- select event and a patch-change event, the gus-driver & its 
supporting software could simply load that patch in.  sounds like 
increment patchloading, sure....  well how about incremental bank-loading 
??  can the gus load-in a whole Bank when given a bank=select event ?

the whole reason i got the gus was for being able to access TONS of 
patches, and EASILY.. if it turns out that i'd have to change the 
Ultrasnd.ini file for Every Song so that the patches i wanted would load 
in from bank 0, then i'd feel somewhat deceived !

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

End of GUS Musician's Digest V10 #8
***********************************

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

                       FTP Sites                     Archive Directories
                       ---------                     -------------------
Main N.American Site:  archive.orst.edu              pub/packages/gravis
                       wuarchive.wustl.edu           systems/ibmpc/ultrasound
Main Asian Site:       nctuccca.edu.tw               PC/ultrasound
Main European Site:    src.doc.ic.ac.uk              packages/ultrasound
Main Australian Site:  ftp.mpx.com.au                /ultrasound/general
                                                     /ultrasound/submit
South African Site:    ftp.sun.ac.za                 /pub/packages/ultrasound
Submissions:           archive.epas.utoronto.ca      pub/pc/ultrasound/submit
Newly Validated Files: archive.epas.utoronto.ca      pub/pc/ultrasound

Mirrors:               garbo.uwasa.fi                mirror/ultrasound
                       ftp.st.nepean.uws.edu.au      pc/ultrasound
                       ftp.luth.se                   pub/msdos/ultrasound

                       Gopher Sites                  Menu directory
                       ------------                  --------------
Main Site:             src.doc.ic.ac.uk              packages/ultrasound

                       WWW Pages
                       ---------
Main Site:             http://www.cs.utah.edu/~debry/gus.html

Main European Site:    http://src.doc.ic.ac.uk/packages/ultrasound/
Main Australian Site:  http://ftp.mpx.com.au/archive/ultrasound/general/
                       http://ftp.mpx.com.au/archive/ultrasound/submit/
                       http://ftp.mpx.com.au/gravis.html
                       
Mirrors:               http://www.st.nepean.uws.edu.au/pub/pc/ultrasound/

MailServer For Archive Access: Email to <mail-server@nike.rz.uni-konstanz.de>
                               Email to <ftpmail@doc.ic.ac.uk>

New Submit Files Mailing List: Email to <listproc@uni-konstanz.de>
                         with content "subscribe epas-list <your-name-here>"

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


