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