💾 Archived View for spam.works › mirrors › textfiles › music › netjam captured on 2023-06-16 at 19:18:51.
-=-=-=-=-=-=-
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