textfiles/music/netjam

				   
				   
	       Guide to Operation for NetJam, Berkeley
			    9 October 1991
				   
		   Copyright 1990, 1991 Craig Latta
				   
You may do anything you like with this document, except sell it.  This
  was derived from K. Richard Magill's (rich@sendai.ann-arbor.mi.us)
initial suggestions (copyright 1990 Digital Works, Ltd., with only the
  right to profit retained), and is available via anonymous ftp from
       scam.Berkeley.EDU (128.32.138.1), as /misc/netjam/guide.


What Is it?

	NetJam provides a means for people to collaborate on musical
compositions, by sending Musical Instrument Digital Interface (MIDI)
and other files to each other, mucking about with them, and resending them. 
All those with MIDI-compatible (and other interesting) equipment, access 
to emailing and compression facilities (specified below) and the Internet, 
and an interest in making music (who isn't?) are encouraged to participate.
All participant and composition information is documented, and the most actions, such
as subscription, submission, and information distribution, are automated.

	If there is interest, the NetJam group may branch out to the
support {soft/hard}ware other than sequencers. For example, there are a bunch 
of interesting sound synthesis programs out there, like CSound for the NeXT.

	This group has the following addresses, where "xcf" is 
xcf.Berkeley.EDU:

	Address:			Where the mail goes:
	-------				-------------------

	netjam@xcf			to me, latta@xcf, the "moderator",
						for general NetJam issues
						and submissions.
	netjam-request@xcf		to me again, for NetJam requests: 
						getting	on the mailing list,
						etc.
	netjam-users@xcf		to all the people on the NetJam 
						mailing list.

	Submissions, participant info, and other stuff is archived on
scam.Berkeley.EDU (128.32.138.1), where it is available via anonymous ftp.

	Some things are available via automatic mail. To receive them, send
mail to netjam-request@xcf with one of the following phrases in the subject
line:

	Phrase:				Action:
	------				------

	request for info		requests this document
	request for scripts		requests UNIX scripts for 
						packing/unpacking submissions
	personal info			submits personal information for 
						NetJam database
	add me:unix			subscribes under the unix format
	add me:mac			subscribes under the mac format
	add me:amiga			subscribes under the amiga format
	add me:atari			subscribes under the atari format
	add me:pc			subscribes under the pc format
	add me:none			subscribes for discussion only
	remove me			unsubscribes
	submission:unix			submits a unix submission
	submission:mac		 	submits a mac submission
	submission:amiga		submits an amiga submission
	submission:atari		submits an atari submission
	submission:pc			you guessed it... submits a pc 
						submission


The list will grow with the demand for additional things.
	
	Why does this group exist, given the existence of other various 
bulletin boards and such? Mainly because I think the NetJam idea will evolve 
more quickly and fruitfully with many people involved, trying different 
approaches. 

	Also, UC Berkeley is fast becoming an interesting place for "Computer 
Music". NetJam, in conjunction with the Berkeley Electronic and Computer 
MUsic Group (BECMuG) can inspire more interest in the field. Given the 
existence of BECMuG, with its membership of roughly 80 people, NetJam has a 
good potential base of people who can work on compositions in this communal, 
moderated, electronic way, as well as in person. And if interest in NetJam
extends beyond Berkeley, all the better; the location of its members is 
inherently unrestricted.


Who's Out There?

	Interested people become involved by sending a request for being
on the NetJam mailing list to me, via netjam-request@xcf. Upon being added
to the group, they will be asked to provide some sort of description of 
themselves: what kind of stuff they write, what kind of equipment they have,
etc. This way, any member can find out about prospective collaborators by 
looking through these descriptions (which would be kept, organized, and
distributed by me).


How Do We Work Together?

	At some point, someone gets an idea for a piece. Then, 
that person composes something (works out a progression, a riff,
a rhythm, some lyrics, sonorities, algorithms for doing any of the 
preceeding, etc.), and emails it to the moderator (me) via two kinds of
files. One kind is for the data (MIDI or other) itself, and the other is
for documenting the data ("README"). The formats of these files are described 
below. The moderator then sends out the submission to all the relevant people
in their preferred format, and archives (in a non-duplicating manner) the
submission for subsequent retrieval (in "unix" format only -- see the 
format explanations below) via anonymous ftp. Each composition 
evolves, in that the collaborators incorporate changes to the data file, and 
append the documentation for it to the README file.
	When new compositions start, they have associated with them 
descriptions of their own. Just as members of the group can see who's out 
there for collaborating, they can see what compositions are in progress. 
	If composers want to attach themselves to certain kinds of
projects, they can find out what's out there from a list of "initial
composers" and their attendant composers, with short summaries of
the projects. Interested composers can then contact the initial 
composers to get a grip on what's really going on with each project
(what's been done, references on the other composers, influences,
stylistic considerations, etc.)

	I shall maintain and distribute this "master list",
as well as assist in any physical reproduction we might like to have later
(notation, mixing, mastering, distribution, copyright issues). Real-time
jamming seems iffy at best, but I'm looking into it.

	I think the initial composer/instigator should have the most 
creative control over what gets assembled (at least, over whatever "final 
product" gets distributed including his/her original ideas). This
extends to copyrights, in that everyone in a particular group should
agree on the phrasing of the copyright(s) for their work, before they 
start and thereafter, with the original composers having the final say 
in the matter.
	Of course, the easiest way to deal with this issue is to make
the works Public Domain. I, for one, will instigate and contribute gladly 
to Public Domain works, as have many others in the past. I hope there
won't be much wrangling on these points. The original idea, after all, 
was to JAM!


File Formats

	MIDI jams

	MIDI jams will be transmitted as two files.  The first file 
will be a standard midi file, format 1.  The second file will be a flat
text file for documenting what's in the midi file (a README).  The
flat text file should have end of line markers appropriate for your
machine.

	So, the raw files should be called: 

	<title>.README
	<title>.mid


	To simplify interchange problems, I ask that you submit your work
in one of the following formats.  I also ask that you choose one
of the following formats and I will distribute all work to you in your
chosen format.  In other words, you will send your work in your
favorite format, I will convert to all others and remail to each
person in his/her favorite format. If you have any suggestions 
or comments about the file formats, mail to netjam@xcf.berkeley.edu.

	The formats will be:

	(format:unix) a uuencode(1)'d, compress(1)'d 'tar(1)' file. Its final
system name before submission should be <title>.tar.Z.uu. The 'tar' file should
contain the jam's README and MIDI files. I will make a shell script for packing
and unpacking available to anyone who wants it. Just mail to 
"netjam-request@xcf", with a subject line containing "request for scripts". 
Or, you can get them via anonymous ftp from xcf.Berkeley.EDU (128.32.138.1), 
as /misc/netjam/scripts.shar (instructions inside).

	(format:mac) a uuencoded (uudecode strips mail headers... :)
stuffit archive. Its final system name before sending should be <title>.sit.uu.
It contains the usual two files.  The MIDI file will be of type 'Midi', creator
'MACA', and the doc file will be of type 'TEXT' intended for use with 
'teachtext'. Stuffit on the mac side can combine, split, binhex, un-binhex, 
archive, and unarchive. Stuffit is shareware, available via anonymous ftp from 
sumex-aim.stanford.edu (36.44.0.6). You can read and edit the 'TEXT' file with 
'teachtext'. 'teachtext' comes with MacOS.

	(format:max) same as the mac format, for the distribution of
Max objects and patchers, except that the data will be for Max, not
necessarily MIDI.

	(format:amiga) a uuencoded zoo archive. Its final system name before 
sending should be <title>.zoo.uu. I'll include icons if someone sends me some.

	(format:atari) a uuencoded zoo archive.

	(format:pc) a uuencoded zoo archive.

	Please be sure that your files are of mode 644 (-rw-r--r--)
before uuencoding them.

	If your submission is greater than 25 Kb in size, please split(1)
it before sending. The current NetJam scripts don't provide for this, but they
will, soon.

	If you need copies of 'zoo' a UNIX version of 'stuffit' (which only
makes archives and doesn't 'binhex', etc.), or a UNIX utility to
"unstuff" stuffit archives, called 'unsit', you can get them via
anonymous ftp from xcf.Berkeley.EDU (128.32.138.1), in the "/src/utils" 
directory. The other necessary software is standard UNIX or specific to 
your machine(s) (telecommunications software, for example).

	Remember to use the "binary" mode of 'ftp' when grabbing binary
files!


Track Assignments

	Please limit yourself to one and only one midi channel.  We have to
presume that people have multi-timbral capabilities, but we can't
assume multiple midi ports.  We also can't (yet) assume patch
switching at all.  (Exception, guitar controllers pretty much require
six channels and that eats a big part of a midi wire.  I think this
should be allowed only if all participants agree.

	You may split your channel, and I'll detail that under "Track
Contents" below.

	Initially, please don't touch any channel other than your own.  I 
think there's too much potential for creative argument here, and I think we
are more interested in actually producing something listenable. The people
in a group can hack each others tracks later if they agree on a method.
If you have to hack another channel in order to hear it, be sure to
save the original so you can add the final version of your track back
into the original.

	If you think that a previous track contains "mistakes", feel free to
change your local copy and to mail the original author.  But please
add your track to the original, not your changed copy.  Let the
original author fix his own mistakes.

	"Sketch tracks" are allowed and encouraged.  A sketch track is
defined as a track whose sole purpose is to give the piece form in the
early stages.  That is, the author intends that the track be dropped
as soon as the piece has enough form to hold rhythm and or chord
progressions on its own.


Notation

	If people desire graphic representations of NetJam stuff, I'm
willing to feed MIDI files into a music notation program (Finale,
troff-music, or MuTeX, others coming), do minor cleaning up, and send out 
the resulting PostScript or TeX files. If others can do similar things, 
let me know, so we can coordinate notation efforts. The composers in each 
group should approve any graphic notation of their works which go outside 
the group. I have a feeling this aspect of things would be hard to get 
working, as producing acceptable hardcopy  notation from MIDI files is 
still a difficult thing to do.
	ASCII notation of music is generally tedious, but notating percussion
seems to be bearable. A currently-used format consists of a legend and a series
of templates. The legend describes, at least, what instruments are used in the 
piece and how they are indicated in the templates. Each template indicates a 
range of measures, the instruments used in that range, and their states 
(on, 'x', or off, '.') for each subdivision of the measures in the range. The 
'|' symbol is used to indicate barlines, and the ':' symbol is used to make 
divisions within a bar easier to see. Here's an example:

	 Written for Yamaha RX-21
         Legend (all numbers decimal):
		45	BD	(Bass Drum)
		52	SD	(Snare Drum)
		57	HHCl	(Hi-hat closed)
		60	Cym	(Cymbal)

	 Measure 18
		HHCl:	....:....|.xxx:.xxx
		BD:	x...:x...|x...:x...
		SD:	xxx.:....|....:....
		Cym:	....:x...|....:....


Track Contents

	The idea here is to simplify things for a group's first attempts and 
to make sure the piece is renderable by everyone involved.

	Voicings:

	Whatever patch you use should be described at least in the README.
Please use generic terms so that someone on a different tone generator
can get close on at least the envelope.  You'll also have to give
some clue as to the number of voices needed for your part.  Later, others
in the group can hammer out patch exchanges and the like.  If you include 
patch changes, document them well in the README. If you use keyboard splits,
document where the splits are, and what's on either side of them.

	Controller Info:

	Keep in mind that most boxes can handle at least the basics, but
more exotic data like poly pressure may not be understood by many. If your 
controller data is extremely important to your part, be sure to give a clue 
in the description of your patch. Of course, it's a good idea to see what
data everyone in the group can send and receive before composing with it.

	No Looping:

	This is just for simplicity.  Most sequencers can copy data from one
place to another so this shouldn't cause many problems.


Documentation

	The README file should contain general descriptions of what you've
done, track(s) used, a generic description of your patch, your splits if
you used any, your name, and your email address. A README template will
probably emerge from NetJam activity.
	Initially, please also include a statement to the effect that you 
release your work to the public domain. Contributions to Public Domain 
compositions will be considered Public Domain.


Great... I've Joined. Now What Do I Do?

	The first step is for you to give some information about 
yourself, so that I can keep it in the database of composers and 
compositions for the reference of interested people. You should include 
your name and email address, preferred NetJam format (currently: UNIX,
mac, pc, amiga, and atari), and equipment you use. Everyone
is highly encouraged to include their musical interests, 
influences, philosophies, and anything else which might possibly 
be relevant. Send it all to netjam-request@xcf. The database may be edited for 
readability.

	At some point, you might think of some musical idea, or
want to add to someone else's and submit it, by email, in two types of
files: data (MIDI or other) and a README. The form of the README is plain 
text, and its format is outlined above. The format of MIDI files
should be one of those given above. Remember, other files relating to 
musical data (besides MIDI, e.g., scores, lyrics, digital samples, etc.) may 
be submitted, in the README format (until more specific formats are developed).

	Under no circumstances should any part of a submission be larger than 25
kilobytes. It isn't pretty when mailers choke! If it seems a submission is 
particularly large, check with me first to find the best way of 
compressing/encoding it for sending. 

	All submissions should be sent to netjam@xcf.Berkeley.EDU. I can then 
send out the submission to people in their preferred formats, and archive 
it on scam (in "unix" format only, due to space constraints). The newest 
versions of all compositions will also available via anonymous ftp from scam, 
in the /misc/netjam/submissions directory. 
	The netjam-users address is for matters of interest to all NetJammers, 
and probably won't include submissions most of the time, due to 
incompatibilities between the equipment of a particular participant and the 
rest of the NetJam group.


Administrivia

	If you're willing to help out with any of the mechanics of
this project, let me know. Some parts of it are best centralized, but
others (like producing hardcopy notation, collecting software, and
coverting files) might be efficiently handled by several people.



	Thanks very much for your interest; I look forward to hearing (and I
do mean HEARING) from you!



		Craig Latta

		Music / EECS student, XCF, CNMAT, DSP, BECMuG guy, etc.
			(Read my .plan!)

		latta@xcf.Berkeley.EDU