From NADC.NADC.NAVY.MIL!bkirsch Sun Mar 29 05:15:32 1992 Return-Path: Received: from 26.0.0.24 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Sun, 29 Mar 92 05:15 PST Received: by NADC.NADC.NAVY.MIL (5.59/1.0 ) id AA17875; Sun, 29 Mar 92 08:12:24 EST Date: Sun, 29 Mar 92 08:12:24 EST From: bkirsch@NADC.NADC.NAVY.MIL (B. Kirsch) Message-Id: <9203291312.AA17875@NADC.NADC.NAVY.MIL> To: aieta@drum.ils.nwu.edu, greenejl@mentor.cc.purdue.edu Subject: Re: Universal samples? Cc: eps@reed.edu Just having the samples and not the parameters to tweek them (ADSR, filter params etc.) does not seem like a good idea because it will take major effort to take those samples (or multi-samples) to get the sound "right". Maybe, separate files could be stored. One for the sample itself, and another set of files, each for different samplers, of the parameters. For example, the original came from an EPS, indicate that in either the parameter file or a readme file. If anyone ports those samples to another sampler, their parameter file can be uploaded separately, and the readme file should be update. Oops, I think I just introduced another file format. Sorry. Barry Kirsch bkirsch@nadc.navy.mil From yuma.ACNS.ColoState.EDU!eroth Sun Mar 29 10:54:51 1992 Return-Path: Received: from 129.82.100.64 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Sun, 29 Mar 92 10:54 PST Received: by yuma.ACNS.ColoState.EDU (AIX 3.1/UCB 5.61/4.03) id AA37563; Sun, 29 Mar 92 11:54:41 -0700 Date: Sun, 29 Mar 92 11:54:41 -0700 From: eroth@yuma.ACNS.ColoState.EDU (Ed Roth) Message-Id: <9203291854.AA37563@yuma.ACNS.ColoState.EDU> To: eps@reed.edu Subject: ghk vs. gkh Cc: eroth@yuma.ACNS.ColoState.EDU I noticed that there is a directory on denial.reed.edu that is called ghk. I assume this stands for Goh King Hwa's disk dump standard which means it should be called gkh. There seems to befiles with both gkh and ghkbe files with both extensions in that directory. Are they something different or are we just confused about the order of the initials?s From psy.uwa.oz.au!scott Sun Mar 29 17:44:37 1992 Return-Path: Received: from 130.95.176.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Sun, 29 Mar 92 17:44 PST Received: by wapsy.psy.uwa.oz.au (5.61+IDA+MU) id AA08850; Mon, 30 Mar 1992 09:43:27 +0800 Date: Mon, 30 Mar 1992 09:43:27 +0800 From: scott@psy.uwa.oz.au (Scott Fisher) Message-Id: <9203300143.AA08850@wapsy.psy.uwa.oz.au> To: eps@reed.edu Subject: An advert I saw... I posted this before but naaaaaaaa response :-) Time for another non-sample-swapping-post anyway As seen in the "bootique" section of TH... ----------------------------------------------------------------------------- RADIO READY (For EPS/16+) "Percussion and Bass" Vol 1-10 "synth & Keys" Vol 1-10 Each volume contains 30 disks. Each volume is only $45. Yes we have the lowest prices in the world. But don't let that fool you - check out what you are getting! Each sample is Pre-Effected (Harmonized, reverbed, EQ-ed, sonic maximised in true stereo, and for the first time ever on sampled disks...3-D Space Surround Sounded!!!) Customized sources like JD800, SY99 D4, 01/W, MPS etc etc...And oh yea, 100% money back Garantee. Credit Cards, MO, Checks: RADIO READY, PO BOX 677, Berkeley, CA 94701. PH: (501) BEAT-808. ----------------------------------------------------------------------------- Sooooo....does anyone know amything about them? Has anyone got any of their samples? I know how difficult it is to make "good" samples, I am wondering if these sounds are not looped or something? 30 disks for $45 appears too good to be true...so what gives, perhaps someone in the area could call them up and find out. If these are anywhere near "decent" sounds you are looking at the bargan of a lifetime. >"Percussion and Bass" Vol 1-10 >"synth & Keys" Vol 1-10 >Each volume contains 30 disks. Each volume is only $45. Yes we have the Does this mean that they have 300 disks of "Percussion and Bass" and 300 disks of "synth & keys"? Thanks in advance Regards Scott. _______________________________________________________________________________ Scott Fisher [scott@wapsy.uwa.oz] PH: Aus [61] Perth (09) Local (380 3574). _--_|\ N Department of Psychology / \ W + E University of Western Australia. Perth --> *_.--._/ S Nedlands, 6009. PERTH, W.A. v *** ERROR 144 - REBOOT? is a registered trademark of ENSONIQ Corp *** ------------------------------------------------------------------------------- From eos.ncsu.edu!aabuinev Sun Mar 29 18:51:31 1992 Return-Path: Received: from 152.1.25.6 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Sun, 29 Mar 92 18:51 PST Received: from c00364-247dan.eos.ncsu.edu by eos05a.eos.ncsu.edu (5.65b/SAM 07-20-90 10:07:54) id AA25725; Sun, 29 Mar 92 21:51:10 -0500 Posted-Date: Sun, 29 Mar 92 21:50:58 EST Received: by c00364-247dan.eos.ncsu.edu (5.57/Ultrix3.0-C) id AA05256; Sun, 29 Mar 92 21:51:02 -0500 From: aabuinev@eos.ncsu.edu Message-Id: <9203300251.AA05256@c00364-247dan.eos.ncsu.edu> To: scott@psy.uwa.oz.au (Scott Fisher) Subject: Re: An advert I saw... Cc: eps@reed.edu Date: Sun, 29 Mar 92 21:50:58 EST > be true...so what gives, perhaps someone in the area could call them up > and find out. If these are anywhere near "decent" sounds you are looking > at the bargan of a lifetime. Well, I tried calling them about a month ago or so and just got a "number disconnected" message... Have they advertised in recent TH's? Maybe it was a quirk, I might try them again (agreed, it sounds like a fantastic deal) ... If anyone has gotten samples from them (or know if this is their correct #), please let us know. So far the best deals I've seen are for the Rubber Chicken Microwave (Wavestation samples) as well as RC VFX volume samples (I've got all 3 sets and they're pretty good... For 100 dollars they doubled the total number of samples in my collection so I was quite happy with the value).. Aris From millie.loc.gov!jeff Sun Mar 29 19:34:11 1992 Return-Path: Received: from 140.147.2.12 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Sun, 29 Mar 92 19:34 PST Received: from millie.loc.gov by rs1.loc.gov (AIX 1.3/4.03) id AA10899; Sun, 29 Mar 92 22:33:36 -0500 Received: by millie.millie (4.1/SMI-4.1-jjm2) id AA20658; Sun, 29 Mar 92 22:30:36 EST Date: Sun, 29 Mar 92 22:30:36 EST From: jeff@millie.loc.gov (Jeff Mallory) Message-Id: <9203300330.AA20658@millie.millie> To: eps@reed.edu Subject: Radio Ready A note from an ex-Bay Area person: If Radio Ready is in Berkeley, their area code should be (510)BEAT-808. Don't know if this was a transposition or a typo in the original ad. Hope this helps. jeff jeff@millie.loc.gov From world.std.com!djk Sun Mar 29 22:46:46 1992 Return-Path: Received: from 137.39.1.7 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Sun, 29 Mar 92 22:46 PST Received: from world.std.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27481; Mon, 30 Mar 92 01:46:31 -0500 Received: by world.std.com (5.61+++/Spike-2.0) id AA24619; Mon, 30 Mar 92 01:46:30 -0500 Date: Mon, 30 Mar 92 1:46:28 EST From: Dan J Keldsen To: adamson@itd.nrl.navy.mil (Brian Adamson) Cc: eps@reed.edu Subject: Re: EPSREAD/WRITE & SoftPC on the Mac In-Reply-To: Your message of Tue, 24 Mar 92 9:16:33 EST Message-Id: > I tried reading an EPS disk while running Goh King Hwa's > PD EPS disk reader software with SoftPC on the Mac....(drum roll > (sampled)).. > and I get a floppy driver error of some sort. Evidently SoftPC is not > quite true enough to form for this type of application. Were you using SoftPC or SoftAT? I have SoftAT, and I would try out Goh King Hwa's PD EPS disk reader if I had it. Since I have just joined this group, I have no idea how to get it, and what it will do. BTW, while I'm on this thought: Could someone list the programs available (PD or otherwise) available for the EPS on any computer platform? Please give the name, computer, function, PD/Comm (etc.), and where they are available... I greatly appreciate whoever can come up with this little gem of info. Ta ta! Dan Keldsen djk@world.std.com From ads.com!pdel Mon Mar 30 02:49:01 1992 Return-Path: Received: from 128.229.30.16 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Mon, 30 Mar 92 02:45 PST Received: from deimos.ads.com by ads.com (5.65+/1.34v1.3) id AA13268; Mon, 30 Mar 92 02:42:52 -0800 From: pdel@ads.com (Peter Delevoryas) Received: by deimos.ads.com (5.65+/4.7) id AA11679; Mon, 30 Mar 92 02:42:42 -0800 Date: Mon, 30 Mar 92 02:42:42 -0800 Message-Id: <9203301042.AA11679@deimos.ads.com> To: eps@reed.edu Subject: Uploading to denial I started sending some disk files. They're in pub/incoming. I also sent my entire EPS disk listing - it's called EPS_dir.pdel@ads.com.uue. I explain how to identify my files in the listing - don't forget to uudecode it :) PD From itd.nrl.navy.mil!adamson Mon Mar 30 06:30:02 1992 Return-Path: Received: from 128.60.2.2 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Mon, 30 Mar 92 06:29 PST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA15845; Mon, 30 Mar 92 09:28:29 EST From: adamson@itd.nrl.navy.mil (Brian Adamson) Message-Id: <9203301428.AA15845@itd.nrl.navy.mil> Subject: EPS vs EPS 16+ disk format? To: eps@reed.edu Date: Mon, 30 Mar 92 9:28:27 EST X-Mailer: ELM [version 2.3 PL0] >PLEASE include in the readme file whether the disk will work >only in an EPS 16+, or whether we poor souls with original EPS's can >use it. (hint, hint). What can an EPS 16+ owner do to make sure he has submitted a disk which can be read by the "classic" EPS? And, what is the loss (aside from not having effects assigned to the instrument) of doing this? Not having had an EPS before getting a 16+, I'm not sure of the differences aside from 13-bit samples vs. 16-bit and on-board effects on the 16+. -- Brian Adamson NRL Code 5523 adamson@itd.nrl.navy.mil From whitefish.rtsg.mot.com!macenski Mon Mar 30 07:02:07 1992 Return-Path: Received: from 129.188.136.100 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Mon, 30 Mar 92 07:01 PST Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com (4.0/SMI-4.0) id AA23313; Mon, 30 Mar 92 09:02:44 CST Received: from rtsg.mot.com ([136.182.254.10]) by pobox.mot.com (4.1/SMI-4.0) id AA15003; Mon, 30 Mar 92 09:02:42 CST Received: from catfish5.. by rtsg.mot.com (4.0/SMI-4.1) id AA23266; Mon, 30 Mar 92 09:01:21 CST Date: Mon, 30 Mar 92 09:00:30 CST From: macenski@whitefish.rtsg.mot.com (Charles D. Macenski) Message-Id: <9203301500@catfish5> To: bordner@csrd.uiuc.edu Subject: Re: Post the format! Cc: eps@reed.edu . Are there many people on this list in this situation? If there are a lot, . and if they can convice me that it's worth my time, I might be able to . hack out an automatic, or at least semi-automatic, mail server. I haven't . done anything like this before so I don't know how involved it would be, . but I think it is in principle possible. I'll look into it... I too have no access to FTP for "security reasons". I would really like to see an automated mailer for these puppies . Chuck From techno.isc.rit.edu!ECLDCO Mon Mar 30 07:47:05 1992 Return-Path: Received: from 129.21.200.40 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Mon, 30 Mar 92 07:46 PST Date: Mon, 30 Mar 1992 10:47:51 -0500 (EST) From: ECLDCO@techno.isc.rit.edu (Eric Loyd - Data Center Operations, x7320) Message-Id: <920330104751.3f14@techno.isc.rit.edu> Subject: IBM-PC EPS reader? To: eps@reed.edu X-Vmsmail-To: SMTP%"eps@reed.edu" As long as we're all on the subject of disk formats and all, does anyone have any idea where I can get a util that will allow me to directly read my Ensoniq disks on my high density IBM PC? -Eric From denial.reed.edu!niski Mon Mar 30 10:05:04 1992 Return-Path: Received: from 134.10.2.65 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Mon, 30 Mar 92 10:04 PST Received: by denial.reed.edu (/\==/\ Smail3.1.25.1 #25.11) id ; Mon, 30 Mar 92 10:04 PST Message-Id: Date: Mon, 30 Mar 92 10:04 PST From: niski@reed.edu (Joe Niski) Received: by NeXT Mailer (1.62) To: eps@reed.edu Subject: Re: ftp via email > I too have no access to FTP for "security reasons". I would really > like to see an automated mailer for these puppies but pleeeeeease>. Well, my local sysadmin sez "It's more trouble than it's worth to set up a mail server" (in other words, we have 5 weeks of school left and nobosy has the time or energy for THAT right now). He also said: Or, you can direct people to various such servers for generic ftp out on the net -- the best one is probably ftpmail@decwrl.dec.com. Start with a message saying "help" (no subject). i did that, and received a somewhat cryptic but not entirely unusable reply - it seems that you can use that service to get files from any ftp server out there. --- Joe Niski niski@reed.edu Computer User Services Reed College, Portland, OR 97202 503-777-7525 Macintosh is the OS i love to hate, UNIX is the OS i hate to love. From ecn.purdue.edu!philip Mon Mar 30 10:06:19 1992 Return-Path: Received: from 128.46.129.59 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Mon, 30 Mar 92 10:06 PST Received: by en.ecn.purdue.edu (5.65/1.30jrs) id AA13547; Mon, 30 Mar 92 13:05:58 -0500 Date: Mon, 30 Mar 92 13:05:58 -0500 From: philip@ecn.purdue.edu (Philip E Nwokah) Message-Id: <9203301805.AA13547@en.ecn.purdue.edu> To: eps@reed.edu Subject: sound disks I purchased an EPS 16+ a few months ago and am looking for new sounds. I have absolutely NO money (I'm still an undergrad). I was wondering if there was any place I could acquire some sounds for free or if anybody might be kind enough to copy some sounds for me. Any advice would be greatly appreciated since I am just starting out. thanks, Phil. philip@en.ecn.purdue.edu From denial.reed.edu!niski Mon Mar 30 10:46:20 1992 Return-Path: Received: from 134.10.2.65 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Mon, 30 Mar 92 10:45 PST Received: by denial.reed.edu (/\==/\ Smail3.1.25.1 #25.11) id ; Mon, 30 Mar 92 10:45 PST Message-Id: Date: Mon, 30 Mar 92 10:45 PST From: niski@reed.edu (Joe Niski) Received: by NeXT Mailer (1.62) To: eps@reed.edu Subject: System software Hey gang: how about uploading system software for the EPS and the EPS 16+? i have only v.2.35 of the OS for the original EPS, and the only Ensoniq dealer in town is such a butt-head that he won't let me copy the system software because i didn't buy my keyboard there........ thanks, Joe From psychok.dialix.oz.au!leigh Mon Mar 30 18:23:46 1992 Return-Path: Received: from 128.250.1.21 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Mon, 30 Mar 92 18:22 PST Received: from uniwa.uwa.oz.au by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA27930; Tue, 31 Mar 1992 11:24:54 +1000 (from leigh@psychok.dialix.oz.au) Received: by uniwa.uwa.oz.au (5.61+IDA+MU) id AA20671; Tue, 31 Mar 1992 09:24:45 +0800 Received: from psychok by DIALix.oz.au id aa00596; Tue, 31 Mar 92 8:20:49 WST To: DIALix!eps@reed.edu Subject: AIFF questions Date: Tue Mar 31 08:15:53 1992 From: leigh@psychok.DIALix.oz.au Message-Id: <9203310820.aa00596@DIALix.oz.au> >AIFF is supported by expensive programs such as Blank softwares >Alchemy and Digidesign's Sound Designer for the Mac and I believe >the Silicon Beach for the IBM. Does Digidesign's Sound Designer support AIFF as it's native file format? The reason I ask is I have the IBM SampleVision (by Turtle Beach) and it doesn't specifically list AIFF as being supported although it does have a file converter to/from Sound Designer: [Digidesigns] "file format has become the defacto standard for musical sample data on public databases, like PAN, MUSICNET, Midwest MIDI and CompuServe" I presume therefore I have an AIFF convertor, can a Mac/SD person confirm this? >Currently the programs that read/write aiff are expensive, but with the great >hackers in this group, and since the aiff format itself is public, I don't >*think* it would be too hard to shift our efforts towards this ideal. I'm not sure this is an 'ideal', but certainly helpful to people who use machines other than EPS's. Like my earlier mail, I think the final solution could be separating out the sample data (in AIFF) into one file with Sys-Ex data for each sampler in other files. But, given many samples need lots of filter tweaking etc, adopting the EDM file format (not the neccessarily the program) satisfies most people first. All we need now is an EDM file format to AIFF converter and the world will be happy :-). In my spare millisecond I might even attempt it myself. Just need to collate the formats, any one have a AIFF file specification? Leigh Perth, Western Australia From psy.uwa.oz.au!scott Mon Mar 30 18:46:00 1992 Return-Path: Received: from 130.95.176.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Mon, 30 Mar 92 18:45 PST Received: by wapsy.psy.uwa.oz.au (5.61+IDA+MU) id AA10727; Tue, 31 Mar 1992 10:43:59 +0800 Date: Tue, 31 Mar 1992 10:43:59 +0800 From: scott@psy.uwa.oz.au (Scott Fisher) Message-Id: <9203310243.AA10727@wapsy.psy.uwa.oz.au> To: eps@reed.edu Subject: WAVeBOY I just got my WAVeBOY Parallel Effects Disk...Others have raved enough about it. Check out the archives at reed.edu /pub/mailing-lists/eps if you want the details of the package. Having 16 MORE effects algorithms and more flexibility is priceless DO IT NOW BUY IT! :-) Regards Scott. _______________________________________________________________________________ Scott Fisher [scott@wapsy.uwa.oz] PH: Aus [61] Perth (09) Local (380 3574). _--_|\ N Department of Psychology / \ W + E University of Western Australia. Perth --> *_.--._/ S Nedlands, 6009. PERTH, W.A. v *** ERROR 144 - REBOOT? is a registered trademark of ENSONIQ Corp *** ------------------------------------------------------------------------------- From intelhf!uunet!MDCBBS.COM!pirk Mon Mar 30 18:55:35 1992 Return-Path: Received: from local by romulus.reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Mon, 30 Mar 92 18:54 PST Received: by intelhf.hf.intel.com (/\==/\ Smail3.1.24.1 #24.4); Mon, 30 Mar 92 17:50 PST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA16723; Mon, 30 Mar 92 19:56:53 -0500 Received: from mdcbbs.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 195148.17665; Mon, 30 Mar 1992 19:51:48 EST Received: by MDCBBS.COM with UUCP/PMDF (DECUS UUCP); Mon, 30 Mar 1992 14:54 PDT Received: from opshpp4 by MDCBBS.COM (PMDF #12239) id <01GI9CJ2S1B40030JK@MDCBBS.COM>; Mon, 30 Mar 1992 14:54 PDT Received: by opshpp4 (16.7/16.2) id AA17640; Mon, 30 Mar 92 14:58:09 -0800 Date: Mon, 30 Mar 92 14:58:09 PST From: Steve Pirk Subject: Hard disk problems To: intelhf!reed!eps Cc: pirk@OPSHPP4 Message-Id: <01GI9CJ2S1B40030JK@MDCBBS.COM> X-Envelope-To: uunet!intelhf!reed!eps Mailer: Elm [revision: 66.33] Hi everyone, I have been absent from the eps group for a bit, but now I have something meaningful to discuss. I have finally obtained a hard disk for my EPS. I have the original not the 16+. The drive I picked up is a used Macintosh external 40 Mb in a nice CMS case. The guy I picked it up from had to change to a "faster" drive, as we could not get the original one to be seen by the EPS. The actual drive is a connor CP-3040a. My problem, is how to get the EPS to boot off the drive? I have moved the o.s., created the default dirs, and loaded a bunch of samples. I have saved the global parameters and any thing else I can think of, but no boot... The unit still insists on asking me to insert the floppy... help! On a similar note, I noticed that if the system is left on for an hour or so with no disk access, the hard drive will no longer respond, causing a hang, when a disk command is entered. I don't belive this is related to the no-boot problem. It is probably a problem with the disk. (this I can live with considering the price...) My hardware/software config is as follows: o EPS w/Marquist (spell) 4x expander w/scsi o O.S. 2.49 o used mac external scsi - 40 Mb connor o IBM w/cake pro and sample vision (just had to throw that one out, sorry) Any help, comments, Flames, or ideas would be appreciated (ARE appreciated in advance of course). Steve Pirk pirk@mdcbbs.com EDS Unigraphics Division Cypress, CA SJ&L Studios Cypress, CA From RCNVMS.RCN.MASS.EDU!NLEONARD Tue Mar 31 00:39:51 1992 Return-Path: Received: from 134.241.10.5 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 00:39 PST Received: from RCNVMS.RCN.MASS.EDU by RCNVMS.RCN.MASS.EDU (PMDF #12408) id <01GIA392JK74CZ0U73@RCNVMS.RCN.MASS.EDU>; Tue, 31 Mar 1992 03:39 EST Date: Tue, 31 Mar 1992 03:39 EST From: NLEONARD@RCNVMS.RCN.MASS.EDU Subject: subscribe To: eps@reed.edu Message-id: <01GIA392JK74CZ0U73@RCNVMS.RCN.MASS.EDU> X-VMS-To: IN%"eps@reed.edu" Please put me on your mailing list. I am a composer/educator living in Boston. Thank you. Neil Leonard A.K.A. nleonard@ecn.mass.edu From fl08-g.comm.mot.com!schickda Tue Mar 31 05:33:43 1992 Return-Path: Received: from 129.188.136.100 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 05:33 PST Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com (4.0/SMI-4.0) id AA04224; Tue, 31 Mar 92 07:34:15 CST Received: from fl08-g.comm.mot.com ([145.2.121.131]) by pobox.mot.com (4.1/SMI-4.0) id AA29304; Tue, 31 Mar 92 07:34:09 CST Received: by fl08-g.comm.mot.com ( 5.52 (84)/5.17) id AA18380; Tue, 31 Mar 92 08:24:12 EST Message-Id: <9203311324.AA18380@fl08-g.comm.mot.com> From: schickda@fl08-g.comm.mot.com (n/a David Schick) Date: Tue, 31 Mar 92 08:24:07 EST Subject: SCSI - PC connection To: eps@reed.edu Benevolent synth people: I am considering adding a SCSI controller card with a 486 PC I am about to purchase. Is there any way to get sample information from an EPS-16+ over the SCSI interface? My Ensoniq SCSI Interface Operation Manual mentions no protocol for this sort of operation, yet it depicts a Macintosh residing on the same SCSI bus as an EPS. Please email or post to the group - others may be interested. Gratitude in anticipation, Zoltan ------------------------------------------------------------------ | schickda@fl08-g.comm.mot.com | | | | We just THINK we exist in space and time. | ------------------------------------------------------------------ From ira.uka.de!uli Tue Mar 31 07:03:13 1992 Return-Path: Received: from 129.13.10.90 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 07:02 PST Message-Id: Received: from i13d5.ira.uka.de by iraun1.ira.uka.de id aa24695; 31 Mar 92 16:44 MET DST To: eps@reed.edu cc: uli@ira.uka.de Subject: EPS vs. EPS 16+ Date: Tue, 31 Mar 92 16:44:11 +0200 From: Uli Bodenhausen I'm looking for a sampler with a SCSI interface or with an internal HD. These are my requirements: - 2Mbyte of RAM - 12bits are OK - good filters - multimode - good user interface - rack or keyboard version are both OK Information on used gear is hard to get or confusing. Here are some specific questions about the EPS: - Does an EPS with 4 times memory expansion have a SCSI interface or is this optional? - Are there different SCSI interfaces? - Does the EPS differ from the EPS16+ besides having 12 bits only and no effect processors? - What else should be taken into account when buying a used EPS? Basically, I want to know if the '16+' version is worth the price difference. Used prices for an EPS with 4x memory is around DM 2500 ( = $1550). The 16+ is around DM 4500 (= $2700). I've heard that the build-in effects of the 16+ are good. I apologize if there have been many posters about this topic before. If so, could someone give me a pointer to previous posts about that topic? Uli From denial.reed.edu!niski Tue Mar 31 10:32:31 1992 Return-Path: Received: from 134.10.2.65 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 10:31 PST Received: by denial.reed.edu (/\==/\ Smail3.1.25.1 #25.11) id ; Tue, 31 Mar 92 10:31 PST Message-Id: Date: Tue, 31 Mar 92 10:31 PST From: niski@reed.edu (Joe Niski) Received: by NeXT Mailer (1.62) To: eps@reed.edu Subject: aiff converter for macintosh Hi: i put a (Binhexed, Stuffed) copy of SoundHack in the utils directory on denial.reed.edu. SoundHack is a wonderful piece of freeware for converting between Mac file formats (AIFF, SoundDesigner, and others). It also converts file to the format used by NeXTs & Sun workstations (it works for moving things between Mac & NeXT quite nicely). Joe From hpeskdl.fc.hp.com!kdl Tue Mar 31 11:33:06 1992 Return-Path: Received: from 15.255.152.2 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 11:31 PST Received: from hpeskdl.fc.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA24916; Tue, 31 Mar 92 11:31:41 -0800 Received: by hpeskdl.fc.hp.com (16.7/15.5+IOS 3.22) id AA29997; Tue, 31 Mar 92 12:33:49 -0700 From: Kelly Larson Message-Id: <9203311933.AA29997@hpeskdl.fc.hp.com> Subject: Why uuencode? To: eps@reed.edu (EPS Mailing List) Date: Tue, 31 Mar 92 12:33:48 MST Mailer: Elm [revision: 66.33] Do we really need the files at reed.denial.edu uuencoded as well? To me that seems like kind of a waste, what purpose does it serve? It makes the files quite a bit bigger, and adds to the time that it takes to ftp the things. The zip format already checks for validity by running some sort of checksum over it's archived files, I just can't see any reason for the uuencoding. If they needed to be sent by mail, then the uuencoding would be necessary, but why archive things in an ftp site already uuencoded? If the files needed to be sent to somebody it would be easy enough to write a script that would take the file, and uuencode it before sending it off. We would save quite a bit of file space by not having to store them that way. Just wonderin'.... =============================================================================== /\ | / / \ | /\ Kelly Larson /\ / \ /\ | / / \ | /\/ kdl@hpeskdl.fc.hp.com / \/ \ \/\| | /-\ /-\ | |\/ \ Engineering Systems Lab / / \ / | | / / /__/ | |/ \/ Hewlett Packard Company / / / | \ / / | \ / COLORADO! / | \ / / | =============================================================================== From hpsadlu.sad.hp.com!smithj Tue Mar 31 12:18:21 1992 Return-Path: Received: from 15.255.152.2 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 12:18 PST Received: from hpsadlu.sad.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA26774; Tue, 31 Mar 92 12:18:10 -0800 Received: by hpsadlu.sad.hp.com (15.11/15.5+IOS 3.22) id AA22877; Tue, 31 Mar 92 12:18:06 pst Date: Tue, 31 Mar 92 12:18:06 pst From: Jim Smith Message-Id: <9203312018.AA22877@hpsadlu.sad.hp.com> To: eps@reed.edu Subject: ftpmail and uuencoding Kelly Larson writes: >Do we really need the files at reed.denial.edu uuencoded as well? To ><...> >If the files needed to be sent to somebody >it would be easy enough to write a script that would take the file, >and uuencode it before sending it off. We would save quite a bit of >file space by not having to store them that way. For the time being, the solution for those of us who don't have ftp capability seems to be to use ftpmail@decwrl.dec.com. It looks to me like this program will uuencode files for mailing if you tell it to, but I haven't tried it yet. Has anyone else tried it? >From my point of view, if ftpmail won't uuencode them, then they should be uuencoded. Otherwise not. - Jim Smith smithj@hpsad.sad.hp.com From kong.gsfc.nasa.gov!arensb Tue Mar 31 12:32:31 1992 Return-Path: Received: from 128.183.115.33 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 12:31 PST Received: from kong.gsfc.nasa.gov by lego.gsfc.nasa.gov (5.61/1.35) id AA13191; Tue, 31 Mar 92 15:31:36 -0500 Received: by kong.gsfc.nasa.gov (4.1/SMI-4.1) id AA07312; Tue, 31 Mar 92 15:31:33 EST Date: Tue, 31 Mar 92 15:31:33 EST From: arensb@kong.gsfc.nasa.gov (Andrew Arensburger - RMS) Message-Id: <9203312031.AA07312@kong.gsfc.nasa.gov> To: eps@reed.edu Subject: Re: AIFF questions > From leigh@psychok.dialix.oz.au Mon Mar 30 21:38:16 1992 > In my spare millisecond I might even attempt it myself. Just need to > collate the formats, any one have a AIFF file specification? In the interest of Enlightening the World By Wasting Bandwidth, here's an AIFF spec. I don't remember where I got this, but I believe this is a document that was quickly and shabbily converted from MacWord to ASCII, then posted to USENET. -- Andrew Arensburger | "Anyway, it never gets cold on Earth. Cold arensb@kong.gsfc.nasa.gov | enough to freeze water, yes, but not carbon ...!uunet!dftsrv!kong!arensb | dioxide." -- "Fallen Angels" ----- begin included article ------------------------------ Audio Interchange File Format: "AIFF" A Standard for Sampled Sound Files Version 1.2 Apple Computer, Inc. The Audio Interchange File Format (Audio IFF) provides a standard for storing sampled sounds. The format is quite flexible, allowing for the storage of monaural or multichannel sampled sounds at a variety of sample rates and sample widths. Audio IFF conforms to the "EA IFF 85" Standard for Interchange Format Files developed by Electronic Arts. Audio IFF is primarily an interchange format, although application designers should find it flexible enough to use as a data storage format as well. If an application does choose to use a different storage format, it should be able to convert to and from the format defined in this document. This will facilitate the sharing of sound data between applications. Audio IFF is the result of several meetings held with music developers over a period of ten months in 1987-88. Apple Computer greatly appreciates the comments and cooperation provided by all developers who helped define this standard. Another "EA IFF 85" sound storage format is"8SVX" IFF 8-bit Sampled Voice, by Electronic Arts. "8SVX", which handles 8-bit monaural samples, is intended mainly for storing sound for playback on personal computers. Audio IFF is intended for use with a larger variety of computers, sampled sound instruments, sound software applications, and high fidelity recording devices. Data types A C-like language will be used to describe data structures in this document. The data types used are listed below: char: 8 bits, signed. A char can contain more than just ASCII characters. It can contain any number from -128 to 127 (inclusive). unsigned char: 8 bits, unsigned. Contains any number from zero to 255 (inclusive). short: 16 bits, signed. Contains any number from -32,768 to 32,767 (inclusive). unsigned short: 16 bits, unsigned. Contains any number from zero to 65,535 (inclusive). long: 32 bits, signed. Contains any number from -2,147,483,648 to 2,147,483,647 (inclusive). unsigned long: 32 bits, unsigned. Contains any number from zero to 4,294,967,295 (inclusive). extended: 80 bit IEEE Standard 754 floating point number (Standard Apple Numeric Environment [SANE] data type Extended). pstring: Pascal-style string, a one byte count followed by text bytes. The total number of bytes in this data type should be even. A pad byte can be added at the end of the text to accomplish this. This pad byte is not reflected in the count. ID: 32 bits, the concatenation of four printable ASCII character in the range ' ' (SP, 0x20) through '~' (0x7E). Spaces (0x20) cannot precede printing characters; trailing spaces are allowed. Control characters are forbidden. OSType: 32 bits. A concatenation of four characters, as defined in Inside Macintosh, vol II. Constants Decimal values are referred to as a string of digits, for example 123, 0, 100 are all decimal numbers. Hexadecimal values are preceded by a 0x - e.g. 0x0A12, 0x1, 0x64. Data Organization All data is stored in Motorola 68000 format. Data is organized as follows: Referring to Audio IFF The official name for this standard is Audio Interchange File Format. If an application program needs to present the name of this format to a user, such as in a "Save asI" dialog box, the name can be abbreviated to Audio IFF. File Structure The "EA IFF 85" Standard for Interchange Format Files defines an overall structure for storing data in files. Audio IFF conforms to the "EA IFF 85" standard. This document will describe those portions of "EA IFF 85" that are germane to Audio IFF. For a more complete discussion of "EA IFF 85", please refer to the document "EA IFF 85" Standard for Interchange Format Files. An "EA IFF 85" file is made up of a number of chunks of data. Chunks are the building blocks of "EA IFF 85" files. A chunk consists of some header information followed by data: A chunk can be represented using our C-like language in the following manner: typedef struct { ID ckID; /* chunk ID */ long ckSize; /* chunk Size */ char ckData[]; /* data */ } Chunk; ckID describes the format of the data portion a chunk. A program can determine how to interpret the chunk data by examining ckID. ckSize is the size of the data portion of the chunk, in bytes. It does not include the 8 bytes used by ckID and ckSize. ckData contains the data stored in the chunk. The format of this data is determined by ckID. If the data is an odd number of bytes in length, a zero pad byte must be added at the end. The pad byte is not included in ckSize . Note that an array with no size specification (e.g. char ckData[];) indicates a variable-sized array in our C-like language. This differs from standard C. An Audio IFF file is a collection of a number of different types of chunks. There is a Common Chunk which contains important parameters describing the sampled sound, such as it's length and sample rate. There is a Sound Data Chunk that contains the actual audio samples. There are several other optional chunks that define markers, list instrument parameters, store application-specific information, etc. All of these chunks are described in detail in later sections of this document. The chunks in a Audio IFF file are grouped together in a container chunk. "EA IFF 85" defines a number of container chunks, but the one used by Audio IFF is called a FORM. A FORM has the following format: typedef struct { ID ckID; long ckSize; ID formType; char chunks []; } Chunk; ckID is always 'FORM'. This indicates that this is a FORM chunk. ckSize contains the size of data portion of the 'FORM' chunk. Note that the data portion has been broken into two parts, formType and chunks[]. formType describes what's in the 'FORM' chunk. For Audio IFF files, formType is always 'AIFF'. This indicates that the chunks within the FORM pertain to sampled sound. A FORM chunk of formType 'AIFF' is called a FORM AIFF. chunks are the chunks contained within the FORM. These chunks are called local chunks. A FORM AIFF along with its local chunks make up an Audio IFF file. Here is an example of a simple Audio IFF file. It consists of a file containing single FORM AIFF which contains two local chunks, a Common Chunk and a Sound Data Chunk. There are no restrictions on the ordering of local chunks within a FORM AIFF. On an Apple //, the FORM AIFF is stored in a PRO DOS file. The file type is 0xCB and the aux type is 0x0000. On a Macintosh, the FORM AIFF is stored in the data fork of an Audio IFF file. The Macintosh file type of an Audio IFF file is 'AIFF'. This is the same as the formType of the FORM AIFF. Macintosh applications should not store any information in Audio IFF file's resource fork, as this information may not be preserved by all applications. Applications can use the Application Specific Chunk, defined later in this document, to store extra information specific to their application. On an operating system that uses file extensions, such as MS-DOS or UNIX, it is recommended that Audio IFF file names have a ".AIF" extension. A more detailed example of an Audio IFF file can be found in Appendix A. Please refer to this example as often as necessary while reading the remainder of this document. Local Chunk Types The formats of the different local chunk types found within a FORM AIFF are described in the following sections. The ckIDs for each chunk are also defined. There are two types of chunks, those that are required and those that are optional. The Common Chunk is required. The Sound Data chunk is required if the sampled sound has greater than zero length. All other chunks are optional. All applications that use FORM AIFF must be able to read the required chunks, and can choose to selectively ignore the optional chunks. A program that copies a FORM AIFF should copy all of the chunks in the FORM AIFF. To insure that this standard remains usable by all developers, only Apple Computer, Inc. should define new chunk types for FORM AIFF. If you have suggestions for new chunk types, Apple is happy to listen! Please refer to Appendix B for instructions on how to send comments to Apple. Common Chunk The Common Chunk describes fundamental parameters of the sampled sound. #define CommonID 'COMM' /* ckID for Common Chunk */ typedef struct { ID ckID; long ckSize; short numChannels; unsigned long numSampleFrames; short sampleSize; extended sampleRate; } CommonChunk; ckID is always 'COMM'. ckSize is the size of the data portion of the chunk, in bytes. It does not include the 8 bytes used by ckID and ckSize. For the Common Chunk, ckSize is always 18. numChannels contains the number of audio channels for the sound. A value of 1 means monophonic sound, 2 means stereo, and 4 means four channel sound, etc. Any number of audio channels may be represented. The actual sound samples are stored in another chunk, the Sound Data Chunk, which will be described shortly. For multichannel sounds, single sample points from each channel are interleaved. A set of interleaved sample points is called a sample frame. This is illustrated below for the stereo case. For monophonic sound, a sample frame is a single sample point. For multichannel sounds, the following conventions should be observed: numSampleFrames contains the number of sample frames in the Sound Data Chunk. Note that numSampleFrames is the number of sample frames, not the number of bytes nor the number of sample points in the Sound Data Chunk. The total number of sample points in the file is numSampleFrames times numChannels. sampleSize is the number of bits in each sample point. It can be any number from 1 to 32. The format of a sample point will be described in the next section, the Sound Data Chunk. sampleRate is the sample rate at which the sound is to be played back, in sample frames per second. One and only one Common Chunk is required in every FORM AIFF. Sound Data Chunk The Sound Data Chunk contains the actual sample frames. #define SoundDataID 'SSND' /* ckID for Sound Data Chunk */ typedef struct { ID ckID; long ckSize; unsigned long offset; unsigned long blockSize; unsigned char soundData[]; } SoundDataChunk; ckID is always 'SSND'. ckSize is the size of the data portion of the chunk, in bytes. It does not include the 8 bytes used by ckID and ckSize. offset determines where the first sample frame in the soundData starts. offset is in bytes. Most applications won't use offset and should set it to zero. Use for a non-zero offset is explained in the Block-Aligning Sound Data section below. blockSize is used in conjunction with offset for block-aligning sound data. It contains the size in bytes of the blocks that sound data is aligned to. As with offset, most applications won't use blockSize and should set it to zero. More information on blockSize is in the Block-Aligning Sound Data section below. soundData contains the sample frames that make up the sound. The number of sample frames in the soundData is determined by the numSampleFrames parameter in the Common Chunk. Sample Points Each sample point in a sample frame is a linear, 2's complement value. The sample points are from 1 to 32 bits wide, as determined by the sampleSize parameter in the Common Chunk. Sample points are stored in an integral number of contiguous bytes. One to 8 bit wide sample points are stored in one byte, 9 to 16 bit wide sample points are stored in two bytes, 17 to 24 bit wide sample points are stored in 3 bytes, and 25 to 32 bit wide samples are stored in 4 bytes. When the width of a sample point is less than a multiple of 8 bits, the sample point data is left justified, with the remaining bits zeroed. An example case is illustrated below. A 12 bit sample point, binary 101000010111, is stored left justified in two bytes. The remaining bits are set to zero. Sample Frames Sample frames are stored contiguously in order of increasing time. The sample points within a sample frame are packed together, there are no unused bytes between them. Likewise, the sample frames are packed together with no pad bytes. Block-Aligning Sound Data There may be some applications that, to insure real time recording and playback of audio, wish to align sampled sound data with fixed-size blocks. This can be accomplished with the offset and blockSize parameters, as shown below. In the above figure, the first sample frame starts at the beginning of block N. This is accomplished by skipping the first offset bytes of the soundData. Note too that the soundData array can extend beyond valid sample frames, allowing the soundData array to end on a block boundary. blockSize specifies the size in bytes of the block that is to be aligned to. A blockSize of zero indicates that the sound data does not need to be block-aligned. Applications that don't care about block alignment should set blockSize and offset to zero when writing Audio IFF files. Applications that write block-aligned sound data should set blockSize to the appropriate block size. Applications that modify an existing Audio IFF file should try to preserve alignment of the sound data, although this is not required. If an application doesn't preserve alignment, it should set blockSize and offset to zero. If an application needs to realign sound data to a different sized block, it should update blockSize and offset accordingly. The Sound Data Chunk is required unless the numSampleFrames field in the Common Chunk is zero. A maximum of one Sound Data Chunk can appear in a FORM AIFF. Marker Chunk The Marker Chunk contains markers that point to positions in the sound data. Markers can be used for whatever purposes an application desires. The Instrument Chunk, defined later in this document, uses markers to mark loop beginning and end points, for example. Markers A marker has the following format. typedef short MarkerId; typedef struct { MarkerId id; unsigned long position; pstring markerName; } Marker; id is a number that uniquely identifies the marker within a FORM AIFF. The id can be any positive non-zero integer, as long as no other marker within the same FORM AIFF has the same id. The marker's position in the sound data is determined by position . Markers conceptually fall between two sample frames. A marker that falls before the first sample frame in the sound data is at position zero, while a marker that falls between the first and second sample frame in the sound data is at position 1. Note that the units for position are sample frames, not bytes nor sample points. markerName is a Pascal-style text string containing the name of the mark. Note: Some "EA IFF 85" files store strings as C-strings (text bytes followed by a null terminating character) instead of Pascal-style strings. Audio IFF uses pstrings because they are more efficiently skipped over when scanning through chunks. Using pstrings, a program can skip over a string by adding the string count to the address of the first character. C strings require that each character in the string be examined for the null terminator. Marker Chunk Format The format for the data within a Marker Chunk is shown below. #define MarkerID 'MARK' /* ckID for Marker Chunk */ typedef struct { ID ckID; long ckSize; unsigned short numMarkers; Marker Markers[]; } MarkerChunk; ckID is always 'MARK'. ckSize is the size of the data portion of the chunk, in bytes. It does not include the 8 bytes used by ckID and ckSize. numMarkers is the number of markers in the Marker Chunk. numMarkers, if non-zero, it is followed by the markers themselves. Because all fields in a marker are an even number of bytes in length, the length of any marker will always be even. Thus, markers are packed together with no unused bytes between them. The markers need not be ordered in any particular manner. The Marker Chunk is optional. No more than one Marker Chunk can appear in a FORM AIFF. Instrument Chunk The Instrument Chunk defines basic parameters that an instrument, such as a sampler, could use to play back the sound data. Looping Sound data can be looped, allowing a portion of the sound to be repeated in order to lengthen the sound. The structure below describes a loop: typedef struct { short playMode; MarkerId beginLoop; MarkerId endLoop; } Loop; A loop is marked with two points, a begin position and an end position. There are two ways to play a loop, forward looping and forward/backward looping. In the case of forward looping, playback begins at the beginning of the sound, continues past the begin position and continues to the end position, at which point playback restarts again at the begin position. The segment between the begin and end positions, called the loop segment, is played over and over again, until interrupted by something, such as the release of a key on a sampling instrument, for example. With forward/backward looping, the loop segment is first played from the begin position to the end position, and then played backwards from the end position back to the begin position. This flip-flop pattern is repeated over and over again until interrupted. playMode specifies which type of looping is to be performed. #define NoLooping 0 #define ForwardLooping 1 #define ForwardBackwardLooping 2 If NoLooping is specified, then the loop points are ignored during playback. beginLoop is a the marker id that marks the begin position of the loop segment. endLoop marks the end position of a loop. The begin position must be less than the end position. If this is not the case, then the loop segment has zero or negative length and no looping takes place. Instrument Chunk Format The format of the data within an Instrument Chunk is described below. #define InstrumentID 'INST' /* ckID for Instrument Chunk */ typedef struct { ID ckID; long ckSize; char baseNote; char detune; char lowNote; char highNote; char lowVelocity; char highVelocity; short gain; Loop sustainLoop; Loop releaseLoop; } InstrumentChunk; ckID is always 'INST'. ckSize is the size of the data portion of the chunk, in bytes. For the Instrument Chunk, ckSize is always 20. baseNote is the note at which the instrument plays back the sound data without pitch modification. Units are MIDI (MIDI is an acronym for Musical Instrument Digital Interface) note numbers, and are in the range 0 through 127. Middle C is 60. detune determines how much the instrument should alter the pitch of the sound when it is played back. Units are in cents (1/100 of a semitone) and range from -50 to +50. Negative numbers mean that the pitch of the sound should be lowered, while positive numbers mean that it should be raised. lowNote and highNote specify the suggested range on a keyboard for playback of the sound data. The sound data should be played if the instrument is requested to play a note between the low and high notes, inclusive. The base note does not have to be within this range. Units for lowNote and highNote are MIDI note values. lowVelocity and highVelocity specify the suggested range of velocities for playback of the sound data. The sound data should be played if the note-on velocity is is between low and high velocity, inclusive. Units are MIDI velocity values, 1 (lowest velocity) through 127 (highest velocity). gain is the amount by which to change the gain of the sound when it is played. Units are decibels. For example, 0 db means no change, 6 db means double the value of each sample point, while -6 db means halve the value of each sample point. sustainLoop specifies a loop that is to be played when an instrument is sustaining a sound. releaseLoop specifies a loop that is to be played when an instrument is in the release phase of playing back a sound. The release phase usually occurs after a key on an instrument is released. The Instrument Chunk is optional. No more than one Instrument Chunk can appear in a FORM AIFF. MIDI Data Chunk The MIDI Data Chunk can be used to store MIDI data (please refer to Musical Instrument Digital Interface Specification 1.0, available from the International MIDI Association, for more details on MIDI). The primary purpose of this chunk is to store MIDI System Exclusive messages, although other types of MIDI data can be stored in this block as well. As more instruments come on the market, they will likely have parameters that have not been included in the Audio IFF specification. The MIDI System Exclusive messages for these instruments may contain many parameters that are not included in the Instrument Chunk. For example, a new sampling instrument may have more than the two loops defined in the Instrument Chunk. These loops will likely be represented in the MIDI System Exclusive message for the new machine. This MIDI System Exclusive message can be stored in the MIDI Data Chunk. #define MIDIDataID 'MIDI' /* ckID for MIDI Data Chunk */ typedef struct { ID ckID; long ckSize; unsigned char MIDIdata[]; } MIDIDataChunk; ckID is always ' MIDI'. ckSize is the size of the data portion of the chunk, in bytes. It does not include the 8 bytes used by ckID and ckSize. MIDIData contains a stream of MIDI data. The MIDI Data Chunk is optional. Any number of MIDI Data Chunks may exist in a FORM AIFF. If MIDI System Exclusive messages for several instruments are to be stored in a FORM AIFF, it is better to use one MIDI Data Chunk per instrument than one big MIDI Data Chunk for all of the instruments. Audio Recording Chunk The Audio Recording Chunk contains information pertinent to audio recording devices . #define AudioRecordingID 'AESD' /* ckID for Audio Recording */ /* Chunk. */ typedef struct { ID ckID; long ckSize; unsigned char AESChannelStatusData[24]; } AudioRecordingChunk; ckID is always 'AESD'. ckSize is the size of the data portion of the chunk, in bytes. For the Audio Recording Chunk, ckSize is always 24. The 24 bytes of AESChannelStatusData are specified in the AES Recommended Practice for Digital Audio Engineering - Serial Transmission Format for Linearly Represented Digital Audio Data, section 7.1, Channel Status Data. That document describes a format for real-time digital transmission of digital audio between audio devices. This information is duplicated in the Audio Recording Chunk for convenience. Of general interest would be bits 2, 3, and 4 of byte 0, which describe recording emphasis. The Audio Recording Chunk is optional. No more than one Audio Recording Chunk may appear in a FORM AIFF. Application Specific Chunk The Application Specific Chunk can be used for any purposes whatsoever by manufacturers of applications. For example, an application that edits sounds might want to use this chunk to store editor state parameters such as magnification levels, last cursor position, and the like. #define ApplicationSpecificID 'APPL' /* ckID for Application */ /* Specific Chunk. */ typedef struct { ID ckID; long ckSize; OSType applicationSignature; char data[]; } ApplicationSpecificChunk; ckID is always 'APPL'. ckSize is the size of the data portion of the chunk, in bytes. It does not include the 8 bytes used by ckID and ckSize. applicationSignature identifies a particular application. For Macintosh applications, this will be the application's four character signature. data is the data specific to the application. The Application Specific Chunk is optional. Any number of Application Specific Chunks may exist in a single FORM AIFF. Comments Chunk The Comments Chunk is used to store comments in the FORM AIFF. "EA IFF 85" has an Annotation Chunk that can be used for comments, but the Comments Chunk has two features not found in the "EA IFF 85" chunk. They are: 1) a timestamp for the comment; and 2) a link to a marker. Comment A comment consists of a time stamp, marker id, and a text count followed by text. typedef struct { unsigned long timeStamp; MarkerID marker; unsigned short count; char text; } Comment; timeStamp indicates when the comment was created. Units are the number of seconds since January 1, 1904. (This time convention is the one used by the Macintosh. For procedures that manipulate the time stamp, see The Operating System Utilities chapter in Inside Macintosh, vol II ). A comment can be linked to a marker. This allows applications to store long descriptions of markers as a comment. If the comment is referring to a marker, then marker is the ID of that marker. Otherwise, marker is zero, indicating that this comment is not linked to a marker. count is the length of the text that makes up the comment. This is a 16 bit quantity, allowing much longer comments than would be available with a pstring. text contains the comment itself. This text must be padded with a byte at the end to insure that it is an even number of bytes in length. This pad byte, if present, is not included in count. Comments Chunk Format #define CommentID 'COMT' /* ckID for Comments Chunk. */ typedef struct { ID ckID; long ckSize; unsigned short numComments; Comment comments[]; } CommentsChunk; ckID is always ' COMT'. ckSize is the size of the data portion of the chunk, in bytes. It does not include the 8 bytes used by ckID and ckSize. numComments contains the number of comments in the Comments Chunk. This is followed by the comments themselves. Comments are always an even number of bytes in length, so there is no padding between comments in the Comments Chunk. The Comments Chunk is optional. No more than one Comments Chunk may appear in a single FORM AIFF. Text Chunks - Name, Author, Copyright, Annotation These four chunks are included in the definition of every "EA IFF 85" file. All are text chunks; their data portion consists solely of text. Each of these chunks is optional. #define NameID 'NAME' /* ckID for Name Chunk. */ #define AuthorID 'AUTH' /* ckID for Author Chunk. */ #define CopyrightID '(c) ' /* ckID for Copyright Chunk. */ #define AnnotationID 'ANNO' /* ckID for Annotation Chunk. */ typedef struct { ID ckID; long ckSize; char text[]; } TextChunk; ckID is either ' NAME', ' AUTH', '(c) ', or ' ANNO', depending on whether the chunk as a Name Chunk, Author Chunk, Copyright Chunk, or Annotation Chunk, respectively. For the Copyright Chunk, the 'c' is lowercase and there is a space (0x20) after the close parenthesis. ckSize is the size of the data portion of the chunk, in this case the text. text contains pure ASCII characters. It is not a pstring nor a C string. The number of characters in text is determined by ckSize. The contents of text depend on the chunk, as described below: Name Chunk text contains the name of the sampled sound. The Name Chunk is optional. No more than one Name Chunk may exist within a FORM AIFF. Author Chunk text contains one or more author names. An author in this case is the creator of a sampled sound. The Author Chunk is optional. No more than one Author Chunk may exist within a FORM AIFF. Copyright Chunk The Copyright Chunk contains a copyright notice for the sound. text contains a date followed by the copyright owner. The chunk ID '(c) ' serves as the copyright characters ')'. For example, a Copyright Chunk containing the text "1988 Apple Computer, Inc." means ") 1988 Apple Computer, Inc." The Copyright Chunk is optional. No more than one Copyright Chunk may exist within a FORM AIFF. Annotation Chunk text contains a comment. Use of this chunk is discouraged within FORM AIFF. The more powerful Comments Chunk should be used instead. The Annotation Chunk is optional. Many Annotation Chunks may exist within a FORM AIFF. Chunk Precedence Several of the local chunks for FORM AIFF may contain duplicate information. For example, the Instrument Chunk defines loop points and MIDI system exclusive data in the MIDI Data Chunk may also define loop points. What happens if these loop points are different? How is an application supposed to loop the sound? Such conflicts are resolved by defining a precedence for chunks: The Common Chunk has the highest precedence, while the Application Specific Chunk has the lowest. Information in the Common Chunk always takes precedence over conflicting information in any other chunk. The Application Specific Chunk always loses in conflicts with other chunks. By looking at the chunk hierarchy, for example, one sees that the loop points in the Instrument Chunk take precedence over conflicting loop points found in the MIDI Data Chunk. It is the responsibility of applications that write data into the lower precedence chunks to make sure that the higher precedence chunks are updated accordingly. Appendix A - An Example Illustrated below is an example of a FORM AIFF. An Audio IFF file is simply a file containing a single FORM AIFF. On a Macintosh, the FORM AIFF is stored in the data fork of a file and the file type is 'AIFF'. Appendix B - Sending comments to Apple Computer, Inc. If you have suggestions for new chunks to be added to the Audio Interchange File Format, please describe the chunk in as much detail as possible, and give an example of its use. Suggestions for new FORMs, ways to group FORM AIFF's into a bank, and new local chunks are welcome. When sending in suggestions, be sure to mention that your comment refers to the Audio Interchange File Format: "AIFF" document. Send comments to: Developer Technical Support Apple Computer, Inc. 20525 Mariani Avenue, MS: 27-T Cupertino, CA 95014 USA References AES Recommended Practice for Digital Audio Engineering - Serial Transmission Format for Linearly Represented Digital Audio Data, Audio Engineering Society, 60 East 42nd Street, New York, New York 10165 MIDI: Musical Instrument Digital Interface, Specification 1.0, the International MIDI Association. "EA IFF 85" Standard for Interchange Format Files. Electronic Arts. "8SVX" IFF 8-Bit Sampled Voice. Electronic Arts. Inside Macintosh, Volume II. Apple Computer, Inc., Addison Wesley Publishing Company, Inc., 1986. Apple( Numerics Manual, Addison Wesley Publishing Company, Inc., 1986. From intelhf!uunet!tramp.Colorado.EDU!ecen4583 Tue Mar 31 13:11:15 1992 Return-Path: Received: from local by romulus.reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 13:11 PST Received: by intelhf.hf.intel.com (/\==/\ Smail3.1.24.1 #24.4); Tue, 31 Mar 92 12:40 PST Received: from boulder.Colorado.EDU by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA22130; Tue, 31 Mar 92 15:28:08 -0500 Received: from tramp.Colorado.EDU by boulder.Colorado.EDU with SMTP id AA28010 (5.65c/IDA-1.4.4 for ); Tue, 31 Mar 1992 13:27:48 -0700 Received: by tramp.Colorado.EDU id AA24563 (5.65c/IDA-1.4.4/CNS-2.1 for reed!eps@intelhf.UUCP); Tue, 31 Mar 1992 13:27:27 -0700 Date: Tue, 31 Mar 1992 13:27:27 -0700 From: RAVENEL RUTH H Message-Id: <199203312027.AA24563@tramp.Colorado.EDU> To: pirk@mdcbbs.com, intelhf!reed!eps Subject: Re: Hard disk problems I have the same problem with my hard drive for my EPS 16+. I had assumed that it was my drive's fault too since mine are leftover engineering units with downlevel drive firmware in them. They are Maxtor 7120S drives. Since more than one person has seen this problem with more than one make of drive, I would guess that it's an EPS OS problem. -Ali Allen ecen4583@tramp.Colorado.edu (borrowing Ruth's account) From hpsadlu.sad.hp.com!smithj Tue Mar 31 13:37:25 1992 Return-Path: Received: from 15.255.152.2 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 13:36 PST Received: from hpsadlu.sad.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA00681; Tue, 31 Mar 92 13:36:10 -0800 Received: by hpsadlu.sad.hp.com (15.11/15.5+IOS 3.22) id AA25257; Tue, 31 Mar 92 13:36:07 pst Date: Tue, 31 Mar 92 13:36:07 pst From: Jim Smith Message-Id: <9203312136.AA25257@hpsadlu.sad.hp.com> To: eps@reed.edu Subject: AIFF format Thanks, Andrew, for the AIFF format. It looks like it is very flexible, and allows you to store instrument-specific sysex information in the same file with the samples. I also notice that several different forms of looping, detuning, etc. are supported. Now if someone only had the time to put it to good use! - Jim Smith smithj@hpsad.sad.hp.com From intelhf!uunet!tramp.Colorado.EDU!ecen4583 Tue Mar 31 14:15:27 1992 Return-Path: Received: from local by romulus.reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 14:14 PST Received: by intelhf.hf.intel.com (/\==/\ Smail3.1.24.1 #24.4); Tue, 31 Mar 92 14:11 PST Received: from boulder.Colorado.EDU by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18417; Tue, 31 Mar 92 17:02:57 -0500 Received: from tramp.Colorado.EDU by boulder.Colorado.EDU with SMTP id AA00190 (5.65c/IDA-1.4.4 for ); Tue, 31 Mar 1992 15:02:41 -0700 Received: by tramp.Colorado.EDU id AA03256 (5.65c/IDA-1.4.4/CNS-2.1 for reed!eps@intelhf.UUCP); Tue, 31 Mar 1992 15:02:39 -0700 Date: Tue, 31 Mar 1992 15:02:39 -0700 From: RAVENEL RUTH H Message-Id: <199203312202.AA03256@tramp.Colorado.EDU> To: intelhf!reed!eps Subject: Ooops! Sorry about that last Hard Drive message I forgot to mention that that last message about hard drives on the EPS was referring to the EPS not talking to the drive after sitting idle for an hour or so. Boy, killer sentence up there ^ Once again, my appologies. -Ali A. (borrowing Ruth's account) ecen4583@tramp.Colorado.edu From intelhf!uunet!MDCBBS.COM!pirk Tue Mar 31 14:39:21 1992 Return-Path: Received: from local by romulus.reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 14:39 PST Received: by intelhf.hf.intel.com (/\==/\ Smail3.1.24.1 #24.4); Tue, 31 Mar 92 14:28 PST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25858; Tue, 31 Mar 92 17:28:47 -0500 Received: from mdcbbs.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 172657.7001; Tue, 31 Mar 1992 17:26:57 EST Received: by MDCBBS.COM with UUCP/PMDF (DECUS UUCP); Tue, 31 Mar 1992 13:45 PDT Received: from opshpp4 by MDCBBS.COM (PMDF #12239) id <01GIAOEUTMFK003GK5@MDCBBS.COM>; Tue, 31 Mar 1992 13:45 PDT Received: by opshpp4 (16.7/16.2) id AA17963; Tue, 31 Mar 92 13:49:16 -0800 Date: Tue, 31 Mar 92 13:49:15 PST From: Steve Pirk Subject: Followup to EPS H.D. problem To: intelhf!reed!eps Message-Id: <01GIAOEUTMFK003GK5@MDCBBS.COM> X-Envelope-To: uunet!intelhf!reed!eps Mailer: Elm [revision: 66.33] Fellow Hackers, I just got Ali Allen's mail describing the same problem, so I called Ensoniq. The support rep asked me if the drive was terminated. Duh..... I will try it as soon as I get home tonight. I don't know why I did not think of this myself.... I mean EVERY computer here at work has a terminator at the end of the chain..... (actually, the guy I bought it from said "you only need it if you have multiple drives, when I asked..) The rep also said that the drive should "boot" if the O.S. was moved to the disk at the time of format. If the disk is powered up prior to EPS power up, the only reason for not booting (as long as no floppy is in the drive), is that the EPS may not "see" the drive at the right time due to the same termination problem. The terminator I need will be the 50 pin parallel type. The rep mentioned that I could order a 25 pin EPS end terminator from the 800 line. Ensoniq Tech support (215) 647-3930 Ensoniq Toll free order desk (800) 553-5151 (to oredr the SCSI manual) Steve Pirk pirk@mdcbbs.com SJ&L Studios Cypress CA From basser.cs.su.oz.au!paul Tue Mar 31 17:49:59 1992 Return-Path: Received: from 129.78.8.208 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 17:49 PST Message-Id: Date: Wed, 1 Apr 1992 11:38:13 +1000 From: paul@cs.su.oz.au (Paul Craig Tyler) Subject: ftping from denial.reed.edu To: eps@reed.edu I am having trouble getting some of the files from denial.reed.edu in the directory gkh. Some of the files on the disk cause my EPS16+ to hang while loading. This is usually the last file on the disk. Others give warnings about the file being too big. The disks were EPS9, EPS31 and EPS14. Also when I unpacked EPS9, i got 2 disk images from unzip. Does anyone know what is going on here? Anyone had the same problems? Has anyone managed to download these disks completely error free? I'll supply exact information on which files they were tomorrow, I forgot to bring them in today. Thanks Paul From hpeskdl.fc.hp.com!kdl Tue Mar 31 18:07:48 1992 Return-Path: Received: from 15.255.152.2 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 18:07 PST Received: from hpeskdl.fc.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA10955; Tue, 31 Mar 92 18:07:26 -0800 Received: by hpeskdl.fc.hp.com (16.7/15.5+IOS 3.22) id AA00592; Tue, 31 Mar 92 19:09:33 -0700 From: Kelly Larson Message-Id: <9204010209.AA00592@hpeskdl.fc.hp.com> Subject: Re: ftping from denial.reed.edu To: eps@reed.edu (EPS Mailing List) Date: Tue, 31 Mar 92 19:09:33 MST Mailer: Elm [revision: 66.33] > > I am having trouble getting some of the files from denial.reed.edu > in the directory gkh. Some of the files on the disk cause my EPS16+ to > hang while loading. This is usually the last file on the disk. Others give > warnings about the file being too big. The disks were EPS9, EPS31 and EPS14. > Also when I unpacked EPS9, i got 2 disk images from unzip. Does > anyone know what is going on here? Anyone had the same problems? Has > anyone managed to download these disks completely error free? I'll > supply exact information on which files they were tomorrow, I forgot > to bring them in today. > > > Thanks > > Paul > Yah, I downloaded several of the files too, uudecoded, and unzipped them. The uudecode program was complaining that several of the files didn't have an end line. It also complained that EPS14 was truncated. Even after unzipping, most of the files had varying lengths around 819k. It seems like everything should actually be the exact same length. Has anybody else had problems? =============================================================================== /\ | / / \ | /\ Kelly Larson /\ / \ /\ | / / \ | /\/ kdl@hpeskdl.fc.hp.com / \/ \ \/\| | /-\ /-\ | |\/ \ Engineering Systems Lab / / \ / | | / / /__/ | |/ \/ Hewlett Packard Company / / / | \ / / | \ / COLORADO! / | \ / / | =============================================================================== From hpeskdl.fc.hp.com!kdl Tue Mar 31 19:05:15 1992 Return-Path: Received: from 15.255.152.2 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 19:04 PST Received: from hpeskdl.fc.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA13256; Tue, 31 Mar 92 19:03:58 -0800 Received: by hpeskdl.fc.hp.com (16.7/15.5+IOS 3.22) id AA00664; Tue, 31 Mar 92 20:06:02 -0700 From: Kelly Larson Message-Id: <9204010306.AA00664@hpeskdl.fc.hp.com> Subject: Re: ftping from denial.reed.edu To: eps@reed.edu (EPS Mailing List) Date: Tue, 31 Mar 92 20:06:02 MST In-Reply-To: <9204010254.AA25612@deimos.ads.com>; from "Peter Delevoryas" at Mar 31, 92 6:54 pm Mailer: Elm [revision: 66.33] I looked at the tail end of some of the disk images, and there appears to be text appended to the end of the files, such as: EPS PD disk 23 - Star Wars 2 of 2Public Domain / pdel@ads.com This shouldn't be part of an imaga file at all should it? I know the epsread and epswrite utilities add a header, but I didn't think that it added a trailer of any type. It looks like this is probably why the file sizes are all coming out different when they should be the same. =============================================================================== /\ | / / \ | /\ Kelly Larson /\ / \ /\ | / / \ | /\/ kdl@hpeskdl.fc.hp.com / \/ \ \/\| | /-\ /-\ | |\/ \ Engineering Systems Lab / / \ / | | / / /__/ | |/ \/ Hewlett Packard Company / / / | \ / / | \ / COLORADO! / | \ / / | =============================================================================== From psy.uwa.oz.au!scott Tue Mar 31 19:17:05 1992 Return-Path: Received: from 130.95.176.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 19:15 PST Received: by wapsy.psy.uwa.oz.au (5.61+IDA+MU) id AA12572; Wed, 1 Apr 1992 11:14:57 +0800 Date: Wed, 1 Apr 1992 11:14:57 +0800 From: scott@psy.uwa.oz.au (Scott Fisher) Message-Id: <9204010314.AA12572@wapsy.psy.uwa.oz.au> To: eps@reed.edu Subject: Problems with .zip >Yah, I downloaded several of the files too, uudecoded, and unzipped >them. The uudecode program was complaining that several of the files >didn't have an end line. It also complained that EPS14 was truncated. >Even after unzipping, most of the files had varying lengths around >819k. It seems like everything should actually be the exact same >length. Has anybody else had problems? > > Kelly Larson /\ / \ /\ | / / \ | /\/ Mee too, EPS14 had exactly the same problem...I think it may be an idea to search these files out and delete them from the archive. Acutally King Hwa, mentioned that EPSread/write version 2.0 is due out soon so it may be an idea to wait till next week before we get tooo many Meg of version 1.0 gkh files around. Regards Scott. _______________________________________________________________________________ Scott Fisher [scott@wapsy.uwa.oz] PH: Aus [61] Perth (09) Local (380 3574). _--_|\ N Department of Psychology / \ W + E University of Western Australia. Perth --> *_.--._/ S Nedlands, 6009. PERTH, W.A. v *** ERROR 144 - REBOOT? is a registered trademark of ENSONIQ Corp *** ------------------------------------------------------------------------------- From ads.com!pdel Tue Mar 31 19:57:03 1992 Return-Path: Received: from 128.229.30.16 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 19:56 PST Received: from bert.ads.com by ads.com (5.65+/1.34v1.3) id AA25290; Tue, 31 Mar 92 19:54:21 -0800 From: pdel@ads.com (Peter Delevoryas) Received: by bert.ads.com (5.65+/4.7) id AA09910; Tue, 31 Mar 92 19:54:20 -0800 Date: Tue, 31 Mar 92 19:54:20 -0800 Message-Id: <9204010354.AA09910@bert.ads.com> To: kdl@hpeskdl.fc.hp.com Subject: Re: ftping from denial.reed.edu Cc: eps@reed.edu >I looked at the tail end of some of the disk images, and there appears to be text appended to the end of the files Hm, I should probably mention to people to strip off things at the front and end of the files. If noone has been able to get a decent disk out of the files, I'll have to give it another try and check my work. Too early for me to tell what's wrong. PD From ads.com!pdel Tue Mar 31 19:59:27 1992 Return-Path: Received: from 128.229.30.16 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 19:59 PST Received: from bert.ads.com by ads.com (5.65+/1.34v1.3) id AA25312; Tue, 31 Mar 92 19:58:54 -0800 From: pdel@ads.com (Peter Delevoryas) Received: by bert.ads.com (5.65+/4.7) id AA09922; Tue, 31 Mar 92 19:58:52 -0800 Date: Tue, 31 Mar 92 19:58:52 -0800 Message-Id: <9204010358.AA09922@bert.ads.com> To: eps@reed.edu Subject: FTP problems >Scott Fisher writes: it may be an idea to wait till next week before we get tooo many Meg of version 1.0 gkh files around. Yes, I definitely will wait before putting any more stuff on. The thing is, though, that I was able to get the other stuff off okay (not mine). Part of the problem might be what I'm going through to ftp the stuff; it's not all from the PC. I have to bring it over to Unix; in the process, it goes onto an Appleshare(Mac) volume. I'll have to hunt around for a PC telecomm program at work. PD From psy.uwa.oz.au!scott Tue Mar 31 21:51:55 1992 Return-Path: Received: from 134.10.2.61 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 21:51 PST Received: by itchy.reed.edu (/\==/\ Smail3.1.25.1 #25.3) id ; Tue, 31 Mar 92 21:51 PST Received: by wapsy.psy.uwa.oz.au (5.61+IDA+MU) id AA12773; Wed, 1 Apr 1992 13:49:26 +0800 Date: Wed, 1 Apr 1992 13:49:26 +0800 From: scott@psy.uwa.oz.au (Scott Fisher) Message-Id: <9204010549.AA12773@wapsy.psy.uwa.oz.au> To: eps@reed.edu Subject: Locating you all... Let's see how much bandwith I can get away wasting... Exactly where are all these aussies that infest eps@reed.edu? This is an ASCII representation of a map of Australia (you were wondering what that funny looking thing was in my .sig weren't you :-) From now on I will refer to Australia as OZ. We measure its' size X in kilometers, it's about 3000 km across, which translates to about 1800 miles. The little v at the bottom is an Island which is also part of OZ called Tasmania. Indonesia lies to the North, New Zeland to the East (SE really), Africa waaaaay to the West and Antartica to the South. |-- X --| _--_|\ N / \ W + E \_.--._/ S v Likely you have all noticed a few .oz or .au addresses in the eps@reed.edu mailing list. Within the limits of ASCII graphics here we all are... _--_|\ / * <-- Gold Coast (1 hr south of Brisbane) Perth --> *_.--.** <-- Sydney / v Melbourne ------------------------------------------------------------------------------ Place Person address ------------------------------------------------------------------------------ Gold Coast: Steven Gregory [s057@sand.sics.bu.oz.au] Perth: Leigh Smith [leigh@psychok.dialix.oz.au ] Scott Fisher [scott@wapsy.uwa.oz.au] Steve Quartly [steveq@dialix.oz.au] Melbourne: Richard Hagen [richard@mulga.cs.mu.oz.au] Sydney: Paul Tyler [paul@cs.su.oz.au] ------------------------------------------------------------------------------- Although Perth may look like the EPS "capital" of OZ it ain't :-) The importers for Ensoniq equipment in OZ are actually in Melbourne where Richard is. Does anyone have an ASCII map of the their own country? If you do, I am interested in knowing you are, I see people posting regularly but it is often hard to know where you are comming from. Regards Scott. _______________________________________________________________________________ Scott Fisher [scott@wapsy.uwa.oz] PH: Aus [61] Perth (09) Local (380 3574). Department of Psychology University of Western Australia. Nedlands, 6009. PERTH, W.A. ------------------------------------------------------------------------------- From ads.com!pdel Tue Mar 31 23:29:00 1992 Return-Path: Received: from 128.229.30.16 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 23:28 PST Received: from bert.ads.com by ads.com (5.65+/1.34v1.3) id AA25747; Tue, 31 Mar 92 23:28:11 -0800 From: pdel@ads.com (Peter Delevoryas) Received: by bert.ads.com (5.65+/4.7) id AA10139; Tue, 31 Mar 92 23:28:10 -0800 Date: Tue, 31 Mar 92 23:28:10 -0800 Message-Id: <9204010728.AA10139@bert.ads.com> To: scott@psy.uwa.oz.au Subject: Re: Locating you all... Cc: eps@reed.edu Does anyone have an ASCII map of the their own country? Here I am ----- | | | | | | \x \ \ \ \ \ ---- The whole thing is California, the x is s'posed to be Santa Clara (near San Francisco). But then, Scott, you already knew that from when we 'talked'. :) PD From DIALix.oz.au!steveq Tue Mar 31 23:34:42 1992 Return-Path: Received: from 128.250.1.21 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Tue, 31 Mar 92 23:34 PST Received: from uniwa.uwa.oz.au by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA16140; Wed, 1 Apr 1992 17:34:15 +1000 (from steveq@DIALix.oz.au) Received: by uniwa.uwa.oz.au (5.61+IDA+MU) id AA29591; Wed, 1 Apr 1992 15:34:08 +0800 From: Steve Quartly X-Mailer: SCO System V Mail (version 3.2) To: eps@reed.edu Subject: Atari EPS 16+ Disk Wizard Date: Wed, 1 Apr 92 15:12:05 WST Message-Id: <9204011512.aa06518@DIALix.oz.au> Atari, Eps users, Just a quick note to let you know tah I only have 1 bug to fix in the software now (well that is 1 bug that I know of). So it should'nt be too long before I can ftp it. Ill keep you posted! Steve Q. Perth, Western Australia. From ads.com!pdel Wed Apr 1 02:59:10 1992 Return-Path: Received: from 128.229.30.19 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 02:57 PST Received: by saturn.ads.com (5.65+/1.34v1.3) id AA11786; Wed, 1 Apr 92 02:57:10 -0800 Date: Wed, 1 Apr 92 02:57:10 -0800 From: pdel@ads.com (Peter Delevoryas) Message-Id: <9204011057.AA11786@saturn.ads.com> To: eps@reed.edu Subject: FTP problems/fixes Kelly you were right about EPS14.gkh.zip.uue I downloaded it and it wouldn't unzip. Also got the 'short file' error. I uploaded it again, then downloaded, uudecoded, unzipped, and wrote it to disk w/epswrite. Looking at it w/EDM showed all files intact. So give it a try again. Now that I know what 'works' I should be able to fix the bad files and upload new ones without problems. PD From uservx.plk.af.mil!CONLEY Wed Apr 1 06:57:24 1992 Return-Path: Received: from 129.238.32.4 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 06:57 PST Message-Id: Date: 1 Apr 92 07:34:00 MST From: "CONLEY, BOB" Subject: Bad files To: "eps" The following lines document the files from denial.reed.edu which I have been unable to "uudecode" successfully. Each file corresponds to two lines. The first shows the uudecode execution line and identifies the file name; the second line is the uudecode error diagnostic. The other sample files have been uudecoded successfully. The files in this list probably need to be replaced with good copies. + uudecode EPS14.gkh.zip.uue Short file + uudecode EPS15.gkh.zip.uue No end line + uudecode EPS31.gkh.zip.uue No end line + uudecode EPS9.gkh.zip.uue No end line + uudecode PD10.gkh.zip.uue No end line + uudecode PD22.gkh.zip.uue No end line + uudecode PD24.gkh.zip.uue No end line + uudecode PD25.gkh.zip.uue No end line + uudecode PD3.gkh.zip.uue No end line + uudecode PD35.gkh.zip.uue No end line + uudecode PD4.gkh.zip.uue No end line + uudecode PD41.gkh.zip.uue No end line + uudecode PD46.gkh.zip.uue No end line Bob Conley conley@uservx.plk.af.mil From kong.gsfc.nasa.gov!arensb Wed Apr 1 08:38:41 1992 Return-Path: Received: from 128.183.115.33 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 08:37 PST Received: from kong.gsfc.nasa.gov by lego.gsfc.nasa.gov (5.61/1.35) id AA17758; Wed, 1 Apr 92 11:37:16 -0500 Received: by kong.gsfc.nasa.gov (4.1/SMI-4.1) id AA28342; Wed, 1 Apr 92 11:37:14 EST Date: Wed, 1 Apr 92 11:37:14 EST From: arensb@kong.gsfc.nasa.gov (Andrew Arensburger - RMS) Message-Id: <9204011637.AA28342@kong.gsfc.nasa.gov> To: eps@reed.edu Subject: Re: Locating you all... > From scott@psy.uwa.oz.au Wed Apr 1 05:53:08 1992 > Let's see how much bandwith I can get away wasting... I'll second that! :-) > Does anyone have an ASCII map of the their own country? If you do, I > am interested in knowing you are, I see people posting regularly but it is > often hard to know where you are comming from. No, but I can contribute an ASCII map of the state of Maryland (shamelessly stolen from someone's .signature): __________ |/ `-. | \_|.|-, ` - Location: eastern coast of the United States of America, toward the middle. The latitude is approximately that of Madrid, although Maryland is smaller than Spain. That straight line at the top is part of the Mason-Dixon line, which separates the Yankees (in the north, e.g., Pennsylvania) from the Suthunuhs. This basically means that Marylanders can get away with saying "y'all". Although you can't see it without fancy graphics, inside that '\_', there's a square chunk cut out so that we could fit the District of Columbia (better known to you non-Americans as Washington) in. The '|.' is part of the Chesapeake Bay, which is proud to host a new whale, which apparently likes hanging around Baltimore harbor. And now, as a public service, here's a map of the state of Colorado: ------------------- | | | | | | | | | | | | ------------------- (or is that Wyoming?) Thank you for your patience. I think I'll go take my medication now. OB-EPScomment: I noticed at least one address on this mailing list that ends with '.nrl.navy.mil'. I'm at Goddard, which is just up the road from there. Drop me a line if you're interested in getting together sometime. -- Andrew Arensburger | "Anyway, it never gets cold on Earth. Cold arensb@kong.gsfc.nasa.gov | enough to freeze water, yes, but not carbon ...!uunet!dftsrv!kong!arensb | dioxide." -- "Fallen Angels" From uservx.plk.af.mil!CONLEY Wed Apr 1 08:59:33 1992 Return-Path: Received: from 129.238.32.4 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 08:59 PST Message-Id: Date: 1 Apr 92 09:35:00 MST From: "CONLEY, BOB" Subject: Binary/ASCII FTP transfer To: "eps" I would like to discuss a further problem I have seen with the EPS sample files on denial.reed.edu, and which can cause lots of wasted time to the user. The problem concerns the appropriate FTP transfer mode to use when transferring a file. The problem results from having two types of file (ASCII and binary) and two modes of transfer (ASCII and binary) if the mode does not correspond to the file type. Binary files MUST be transferred using binary mode FTP. The file at the destination machine is a byte for byte identical copy of the file on the source. ASCII (ordinary text) files SHOULD be transferred using ASCII mode FTP. This is because the sequence of ASCII control codes which mark the end-of- line varies among different machines/operating systems. Unix, for example, uses only the LF (ASCII line feed); DOS, CR/LF (ASCII carriage return followed by line feed); other machines in my experience have used other codes such as US (ASCII unit separator), or no code at all (using instead a character count byte at the head of each line to indicate the line length). A binary transfer of an ASCII file will not produce a properly formatted ASCII file on the destination machine unless the destination uses the same ASCII file representation for end-of-line as the source machine; this is a particular problem between Unix and DOS, which do not use the same representation. A file produced by "uuencode" is an ASCII file. In order that it be a correctly formatted ASCII file on all machines, it is necessary to use ASCII mode transfer at each step. If binary transfer is used between machines with incompatible ASCII formats, then many potential problems can occur later (uudecode can generate a corrupted file, etc.). All of this has been prompted because at least two files in the gkh directory seem to suffer from this problem: tek-perc.gkh.zip.uu PD46.gkh.zip.uue When these files are transferred from denial.reed.edu to a Unix machine they contain spurious CR's; neither ASCII nor binary FTP will cause the spurious CR's to be eliminated. In the case of tek-perc this causes uudecode to go really haywire, generating a file name which includes a question mark character, and presumably file contents which aren't quite what the originator intended to send. This file is also peculiar in that the spurious CR's occur only on the uuencoded lines, not the human readable narrative which preceeds the uuencoded data. What all of this is meant to suggest is that the originator of the file use ASCII FTP when transferring a uuencoded file to denial.reed.edu. That way the ASCII FTP from denial to the user machine will keep everything correctly formatted. As a final thought, though, I would vote for binary files in Unix compress (.Z) format as the standard representation for our interchange. Bob Conley conley@uservx.plk.af.mil (505) 846-4660 From denial.reed.edu!niski Wed Apr 1 09:42:34 1992 Return-Path: Received: from 134.10.2.65 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 09:42 PST Received: by denial.reed.edu (/\==/\ Smail3.1.25.1 #25.11) id ; Wed, 1 Apr 92 09:42 PST Message-Id: Date: Wed, 1 Apr 92 09:42 PST From: niski@reed.edu (Joe Niski) Received: by NeXT Mailer (1.62) To: eps@reed.edu Subject: various - update Greetings, all: i too found that the tek-perc file was unusable once i downloaded it. i also agree that we should settle on a format for the files we place on the ftp site. Again, the only reason i'm in favor of uuencode is that i've always had better luck with ascii transfers. This is apparently not the case for everyone else, and folks who need to use ftpmail might be able to get the decwerl machine to do the uuencoding for them... Unfortunately, the issue may be moot for the next few days, as NeXT needs to reclaim their cube (i knew it would happen as soon as this started getting fun). denial may not be available later today (Wed, 4/1 - and this is NOT an April Fool's trick 8-( BUT i'll have something figured out, either at reed or elsewhere, by the week's end. We've used a little over 20 megs so far, and that much disk is hard to come by around here (with all those legitimate academic & research users at this college). Finally, the ascii map of Oregon (the asterisk is Portland): Washington state _____ | \ P | \____________ A | * | C | | I | | Idaho F | | I | | C |__________________| California i'll keep you all posted regarding the status of our site. Joe From ads.com!pdel Wed Apr 1 11:14:42 1992 Return-Path: Received: from 128.229.30.16 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 11:14 PST Received: from bert.ads.com by ads.com (5.65+/1.34v1.3) id AA28832; Wed, 1 Apr 92 11:14:03 -0800 From: pdel@ads.com (Peter Delevoryas) Received: by bert.ads.com (5.65+/4.7) id AA10626; Wed, 1 Apr 92 11:14:02 -0800 Date: Wed, 1 Apr 92 11:14:02 -0800 Message-Id: <9204011914.AA10626@bert.ads.com> To: CONLEY@uservx.plk.af.mil Subject: Re: Bad files Cc: eps@reed.edu Thanks for the report. It looks like I goofed in the uuencoding. Just for the heck of it, I tried EPS15.gkh.zip.uue, and was able to make an EPS disk out of it. So even though it gave the 'no end line' message, it still worked. So maybe the other ones will be okay in case people have already downloaded them. In either case, I'll get new versions uploaded. Thanks for the info. PD From ads.com!pdel Wed Apr 1 11:20:13 1992 Return-Path: Received: from 128.229.30.16 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 11:20 PST Received: from bert.ads.com by ads.com (5.65+/1.34v1.3) id AA28906; Wed, 1 Apr 92 11:19:39 -0800 From: pdel@ads.com (Peter Delevoryas) Received: by bert.ads.com (5.65+/4.7) id AA10634; Wed, 1 Apr 92 11:19:38 -0800 Date: Wed, 1 Apr 92 11:19:38 -0800 Message-Id: <9204011919.AA10634@bert.ads.com> To: CONLEY@uservx.plk.af.mil Subject: Re: Binary/ASCII FTP transfer Cc: eps@reed.edu >What all of this is meant to suggest is that the originator of the file use ASCII FTP when transferring a uuencoded file to denial.reed.edu. Ah, possibly the source of my problems. While on this subject, I have a question. When I bring my EPS files (zipped and uuencoded) over to the Unix box, the CR's turn into ^M's because DOS uses a 2-character representation of a CR. I have been stripping these off before I upload the files. Do I need to do this? PD From ads.com!pdel Wed Apr 1 11:22:44 1992 Return-Path: Received: from 128.229.30.16 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 11:22 PST Received: from bert.ads.com by ads.com (5.65+/1.34v1.3) id AA28929; Wed, 1 Apr 92 11:22:06 -0800 From: pdel@ads.com (Peter Delevoryas) Received: by bert.ads.com (5.65+/4.7) id AA10640; Wed, 1 Apr 92 11:22:04 -0800 Date: Wed, 1 Apr 92 11:22:04 -0800 Message-Id: <9204011922.AA10640@bert.ads.com> To: niski@reed.edu Subject: Re: various - update Cc: eps@reed.edu >i'll keep you all posted regarding the status of our site. Should I start moving towards seeing if we can get louie.udel, or wait a bit? We have about 20-30 sigs now; haven't made an exact count. And I haven't advertised in rec.music.synth, so that should produce more. PD From hpsadlu.sad.hp.com!smithj Wed Apr 1 11:37:49 1992 Return-Path: Received: from 15.255.152.2 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 11:37 PST Received: from hpsadlu.sad.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA05003; Wed, 1 Apr 92 11:37:18 -0800 Received: by hpsadlu.sad.hp.com (15.11/15.5+IOS 3.22) id AA02910; Wed, 1 Apr 92 11:37:03 pst Date: Wed, 1 Apr 92 11:37:03 pst From: Jim Smith Message-Id: <9204011937.AA02910@hpsadlu.sad.hp.com> To: eps@reed.edu Subject: yea Here's another "yea" vote for whatever we were voting on before, that you now have 20 or 30 for. Since I can use ftpmail, I now feel qualified to vote. Am I old enough? - Jim smithj@hpsad.sad.hp.com ObQuote: They should iron this. ______________________________________________________________________________ From hpgrrd.gr.hp.com!daver Wed Apr 1 11:53:45 1992 Return-Path: Received: from 15.255.152.2 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 11:53 PST Received: from hpgrrd.gr.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA06032; Wed, 1 Apr 92 11:53:22 -0800 Received: by hpgrrd.gr.hp.com (15.11/15.5+IOS 3.20) id AA00725; Wed, 1 Apr 92 12:53:17 mst Date: Wed, 1 Apr 92 12:53:17 mst From: Dave Ruska Message-Id: <9204011953.AA00725@hpgrrd.gr.hp.com> To: eps@reed.edu Subject: FTP formats & more Cc: daver@hpgrrd.gr.hp.com Subject: Binary/ASCII FTP transfer Bob Conley writes: > I would like to discuss a further problem I have seen with the EPS sample > files on denial.reed.edu, and which can cause lots of wasted time to the > user. The problem concerns the appropriate FTP transfer mode to use when > transferring a file. The problem results from having two types of file > (ASCII and binary) and two modes of transfer (ASCII and binary) if the > mode does not correspond to the file type. > ... > What all of this is meant to suggest is that the originator of the file > use ASCII FTP when transferring a uuencoded file to denial.reed.edu. That > way the ASCII FTP from denial to the user machine will keep everything > correctly formatted. As a final thought, though, I would vote for binary > files in Unix compress (.Z) format as the standard representation for our > interchange. Yeh, it seems like someone jumped the gun at the starting line. We really need to establish AND document the procedures for using an ftp site BEFORE we starting using an ftp site. Also concerning the uuencode thing, a few weeks ago I proposed use of unix compress (.Z) format and binary file transfers (that being the standard on just about every major ftp site I know) but a few people objected. As Kelly had pointed out, you don't need to use uuencode format so that you can have a mail server (for people who can't ftp). The mail server itself can take care of uuencoding. I generally always use BINARY ftp. If I pull over a DOS file which has extra CR's which unix doesn't care for, I pipe it through a dos2ux program which cleans it up (including the control-Z). Joe Niski writes: > i too found that the tek-perc file was unusable once i downloaded it. > i also agree that we should settle on a format for the files we place > on the ftp site. Again, the only reason i'm in favor of uuencode is > that i've always had better luck with ascii transfers. This is > apparently not the case for everyone else, and folks who need to use > ftpmail might be able to get the decwerl machine to do the uuencoding > for them... > Unfortunately, the issue may be moot for the next few days, as NeXT > needs to reclaim their cube .... Hopefully we can take what we've learned with our 'denial.reed.edu' and have better luck with our next site (should we find one). Let's make sure we get resolution on the issues BEFORE we start using it. A recommendation for things we need to resolve: 1) File format for "disk image format" Have we reached consensus on EDM's .EDE format ? Supported by EDM, GKH version 2, and soon to be released Atari & Mac shareware ? There are other platforms which will need encoders/decoders. Can we get the EDM format posted ? Do I need to call Gary to get it ? Once we've agreed on a format we can 'share' disks via mail in a 'common' format. (FYI: Kelly and I have hundreds of PD disks from which we might be convinced to mail some out....) 2) File format for "file image format" Using EDM's .EFE would make sense. The disk image format should give us the biggest bang for the ${currency} for starters, but a file image format will give us some flexibility in the future. 3) Ftp site archive format. Are we going to require ASCII mode transfers (and require uunencoding) or not. How may people believe they can only do ASCII transfers ? And is it worth the extra storage space (30% or more) ? Are these people better off using a mail server ? 4) Ftp site directory and file structure. How do we structure the directories so that people can find what they are looking for ? How do we identify files so that people can know what they contain BEFORE they download it and find out it's (another) sample of a toilet flushing ? Should each file have a .readme file, or should all the descriptions be put in ONE readme file (per directory)? 5) How do we control file access on the ftp site ? Open write access is generally undesirable. You'll find that out the first time someone deletes all your files (by accident). Should we set up an incoming directory which an administator would regulary move out the the appropriate places ? Don't start posting answers to these questions. This is just a PROPOSED list of questions which I think we should discuss BEFORE we leap into another ftp site. I'm sure there are other issues as well. I would suggest what we have 'one' person lead the discussions. My vote would be: Scott (probably out cooking shrimp on his barbee) Fisher. This person could collect the issues, send out a survey, collect and summarize the results, and then make recommendations to us. ---> Send me your vote for 'eps.reed.edu' club leader. I will summarize <--- ---> the results at the end the week (assuming you send me some)... <--- ---> If I don't get any resonse I'll assume this was a bad idea, and <--- ---> I'll go startup a mailing list for frustrated Proteus owners..... <--- Offical electronic ballot: -------------------------------------------------------------------------- | | | My vote for eps.reed.edu club leader is | | | | ( ) | | | -------------------------------------------------------------------------- Return to: daver@hpgrla.gr.hp.com Regards, Dave Ruska From noc.vitalink.com!ejm Wed Apr 1 11:56:07 1992 Return-Path: Received: from 132.240.18.13 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 11:55 PST Received: from yamaha.NOC.Vitalink.COM by mescal.NOC.Vitalink.COM with SMTP id AA14023 (5.65c/IDA-1.4.4 for ); Wed, 1 Apr 1992 11:50:59 -0800 Received: from localhost by yamaha.NOC.Vitalink.COM (5.65+V1.2/V1.3) id AA08778; Wed, 1 Apr 92 11:55:06 -0800 Message-Id: <9204011955.AA08778@yamaha.NOC.Vitalink.COM> To: pdel@ads.com (Peter Delevoryas) Subject: Re: various - update In-Reply-To: Your message of "Wed, 01 Apr 92 11:22:04 PST." Cc: eps@reed.edu Date: Wed, 01 Apr 92 11:55:05 -0800 From: ejm@noc.vitalink.com We should really get our act together on FTP file formats. I, for one, don't believe in uuencoded files when a UNIX-ftp site can transfer to almost any other 8-bit machine without the CR/NL translation issues. uuencode just adds more disk space, more network bandwidth, etc. Besides, most un-arc/un-zip/un-tar/un-whatever-compresed programs have checksums which would have prevented all the bad sample files we have now. I don't think we should approach an "official" ftp site with the mess we have now. It might be very embarrassing. Just my $.02.... ... Erik --- Erik Murrey Vitalink Communications ejm@vitalink.com ... vitanoc!ejm From EBay.Sun.COM!Rick.Wagoner Wed Apr 1 13:15:34 1992 Return-Path: Received: from 192.9.9.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 13:15 PST Received: from EBay.Sun.COM (female.EBay.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA23569; Wed, 1 Apr 92 13:15:22 PST Received: from georwell.EBay.Sun.COM by EBay.Sun.COM (4.1/SMI-4.1) id AA06267; Wed, 1 Apr 92 13:15:20 PST Received: by georwell.EBay.Sun.COM (4.1/SMI-4.1) id AA00403; Wed, 1 Apr 92 13:14:45 PST Date: Wed, 1 Apr 92 13:14:45 PST From: Rick.Wagoner@EBay.Sun.COM (Rick Wagoner) Message-Id: <9204012114.AA00403@georwell.EBay.Sun.COM> To: eps@reed.edu Subject: A BEGINNER'S GUIDE TO FTP I pulled this off comp.binaries.ibm.pc. I will be posting another one on bin files for PC types. Hope this helps. Rick +-----------------------------------------------+ + Rick Wagoner + + Sun Microsystems Education Dept. + + 408-276-5658 + + + + email Rick.Wagoner@EBay.Sun.COM + + or rick.wagoner@Ebay + + or rwagoner@sun.com + + + + or whateverthehell the DNS server mangles my + + address into! + + + +-----------------------------------------------+ + Opinions: MINE! Systems: Theirs! + +-----------------------------------------------+ + Everybody likes to stir the excrement + + but nobody likes to clean the paddle... + +-----------------------------------------------+ [Date of Last Change: 12/26/91 Release 1.6] A BEGINNER'S GUIDE TO FTP Copyright (c) 1991 by Brian O'Neill. Permission to copy this file feely is given, so long as the file remains unmodified. FTP stands for File Transfer Protocol. It allows a person to transfer files between two systems, generally connect over local area networks or wide area networks, such as the Internet. If your hosts system has FTP and is connected to the Internet, you can access very large amounts of archives available on a number of systems, such as Simtel20 or uunet.uu.net. This is a simplified use manual, and will use two examples, one a TOPS-20 system (wsmr-simtel20.army.mil, which has a large base if PD/Shareware MSDOS software), and one Unix system (uunet.uu.net, where archives of the comp.sources newsgroups are kept). The simplest way to initiate FTP would be to give the command 'ftp ', where is the remote system you are connecting to, either a name (wsmr-simtel20.army.mil, if you have an entry in /etc/hosts or are accessing a Domain Name Server, such as bind) or the InterNet address (192.88.110.20, for Simtel20). After a short wait, you will be prompted for your username. If you do not have an account on the remote system, some systems allow you to use 'anonymous'. This gives you a restricted access path, allowing you to access certain files only. You would then be prompted for a password. If you are using your own account, give your password. If you are using 'anonymous', the system may ask you to send your real identity as the password. What you type doesn't matter, but it is suggested to give your mail address. Other systems need a password of 'guest', or something similar. After that, you should receive the FTP prompt (usually ftp>), and now have access. You can get a directory of files be giving a 'dir' command, or if the remote system is Unix-based, 'ls -l' will give the familiar output. On Simtel20, there is a file available in the default anonymous ftp directory that explains what Simtel20 is, and where files are located. The name is 'SIMTEL-ARCHIVES.INFO.nn, where ".nn" is a file generation number. You don't need to specify the file generation number when requesting the file. In fact, it's better not to because you will always get the latest generation that way. Unix systems will all have the familiar directory structure, and moving around is done with the familiar 'cd' or 'cwd' command. TOPS-20 systems have a different structure, but movement is still accomplished with the 'cd' command. I will use Simtel20 as the first example. To start, give the command 'ftp wsmr-simtel20.army.mil' from your shell prompt, or 'open wsmr-simtel20.army,mil' from the 'ftp>' prompt. If this host is not in your /etc/hosts file or you do not have access to a Domain-name Server, use '192.88.110.20' in it's place. After a few seconds, you'll be prompted for your username. Type 'anonymous', and when prompted for password, give your e-mail address (more as a courtesy than anything else), or if you prefer, 'guest'. You should then shortly get back the 'ftp>' prompt. If you receive an error message stating that there are too many anonymous logins, wait a few minutes and try again. Simtel20 has limited access, especially during normal business hours. Now, say you want to see what is stored for MS-DOS programs. Simtel20 is a DEC System-20 running the TOPS-20 operating system. The directory structure is 'DISK:'. For MS-DOS programs, the main directory is 'PD1:'. In here there is a file called 'MSDOS.CRCLST', which is updated almost daily. It contains a list of all files within the MS-DOS subdirectories, along with file size and CRC value. To get this list, first switch to that directory by saying 'cd pd1:' (TOPS-20 is not case sensitive). If you are prompted for another password just ignore the request. When you get the 'ftp>' prompt back, you can then say 'get msdos.crclst'. This will initiate the transfer, and after a few minutes it will be completed. The beauty of Unix is that while you are transfering something big, you can put it in the background and do something else. Say you wanted to get ProComm Plus TD. According to the list, it is in PD1:. So, you can enter 'cd pd1:'. A 'dir' will show all the files in that directory. (You may wish not to use too many 'dir' commands, as they are sometimes fairly slow). Now, you want the file 'pcplustd.arc'. First, you must tell your host what kind of file it is. On most Unix systems, 'binary' or 'set type binary' or 'set type I' will work. However, as Simtel20 runs a different OS that has different word sizes (36 bits) you must specify 'tenex' or 'type L 8' to transfer properly. You can then issue a 'get pcplustd.arc' command, and after a short while, you have ProComm Plus TD. To end your session, enter the 'bye' command. Unix is a little more familiar for most people with Internet access. For example, you might wish to get sources to the latest version of ZOO from uunet.uu.net. First, you give the 'ftp uunet.uu.net' command (or ftp 192.48.96.2), giving 'anonymous' for the username, and your address as the password. You can then use the 'dir' or 'ls -l' commands to scan the directories. After some directory searching, you find it is located in usenet/comp.sources.unix/volume17/zoo2, showing that it was posted in comp.sources.unix, volume 17. Inside that directory, you find 10 parts, labelled part01.Z to part10.Z. As told by the .Z suffix, these files are compressed binary files. You must tell FTP to operate in binary mode, so type 'binary' or 'type I' to set it. You can then do a 'get' for each file. Now you have the original sources to Zoo 2.01. Different systems have different organizations for their files, and the above example is just the way I have it set up. By 'poking' around other systems, you can learn how their files are set up, and zip around much faster. Note, however, that FTP will not allow you outside the FTP 'root' directory, usually ~ftp on most systems. So, poking about the entire system is not permitted. You now have a basic understanding of how to use FTP to get the things you want. I hope this has been of use. Questions and comments welcome. Other features of FTP can be found in the manual - please check there. My E-mail address is oneill@cs.ulowell.edu. Messages regarding problems, complaints or suggestions for Simtel20 should be addressed to 'action@wsmr-simtel20.army.mil'. ----- End Included Message ----- ----- End Included Message ----- From EBay.Sun.COM!Rick.Wagoner Wed Apr 1 14:12:35 1992 Return-Path: Received: from 192.9.9.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 14:12 PST Received: from EBay.Sun.COM (female.EBay.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA07857; Wed, 1 Apr 92 14:12:09 PST Received: from georwell.EBay.Sun.COM by EBay.Sun.COM (4.1/SMI-4.1) id AA10076; Wed, 1 Apr 92 14:12:07 PST Received: by georwell.EBay.Sun.COM (4.1/SMI-4.1) id AA00598; Wed, 1 Apr 92 14:11:32 PST Date: Wed, 1 Apr 92 14:11:32 PST From: Rick.Wagoner@EBay.Sun.COM (Rick Wagoner) Message-Id: <9204012211.AA00598@georwell.EBay.Sun.COM> To: eps@reed.edu Subject: Beginner's Guide to Binaries Here is the posting on binaries as promised. Rick +-----------------------------------------------+ + Rick Wagoner + + Sun Microsystems Education Dept. + + 408-276-5658 + + + + email Rick.Wagoner@EBay.Sun.COM + + or rick.wagoner@Ebay + + or rwagoner@sun.com + + + + or whateverthehell the DNS server mangles my + + address into! + + + +-----------------------------------------------+ + Opinions: MINE! Systems: Theirs! + +-----------------------------------------------+ + Everybody likes to stir the excrement + + but nobody likes to clean the paddle... + +-----------------------------------------------+ [Date of last change 12/26/91 Release 1.3] HOW TO USE BINARIES SENT VIA NEWS AND E-MAIL (c) Copyright 1991 Brian O'Neill. Permission to distrbute this file freely is granted, so long as it remains unmodified. One of the more troubling things to new users is using programs posted to groups like comp.binaries.ibm.pc. This is in part due to the fact that different utilties are needed to decode these files into something more familiar to them. This manual explains how to retrieve binary files posted to UseNet, and also received by e-mail. This manual is divided into several sections, each dealing with a different aspect of what is needed. Here is the basic setup: I. Formats and Standards II. Minimum utilities, and how to get them III. Using UNIX to do the work IV. Using MS-DOS to do the work V. Handling archived files VI. Downloading files from UNIX to MSDOS This manual was written with the new user in mind. If any section is unclear to you, please respond to me via e-mail. Let me know what section, paragraph, and what it was that was unclear. My address is below: Internet: oneill@ulowell.edu UUCP: ...!ulowell!oneill I. FORMATS AND STANDARDS UseNet, and other networks, user groups, and BBS's, all work on some set of standards for sharing files between a diverse arangement of systems. For PC's, the most common standard for files is the archive. This is a binary file which allows a user to place several files into one, while compressing them to save space. Several utilities exist for making and extracting files from archives. The most common are ZOO from Rahul Dhesi, and PKZIP from PKWare. The ZOO standard has been adopted for use in the UseNet newsgroup comp.binaries.ibm.pc for the distribution. Some BBS systems use ZIP, and others use ARC, another format from System Enhancement Associates which is slowly becoming obsolete, and is generally avoided due to recent litigation in court (which I will not discuss here). You will need the appropriate extraction program for the particular format you are dealing with, which usually can be told by the extension name on the file (.ZOO, .ZIP, or .ARC). UseNet and e-mail are based on ASCII text. In other words, they are only able to transmit ASCII files. In order to transmit binary files, they are transformed into ASCII files first. This is accomplished using a program called 'uuencode', another fairly common standard. The file can then be decoded back into binary form using 'uudecode'. These programs are fairly common among UNIX systems, and are increasingly available for MS-DOS. Once again, you will need a version of uudecode to properly handle these files. II. MINIMUM UTILITIES, AND HOW TO GET THEM You will need some form of uudecode, either UNIX or MS-DOS, to decode the binaries. If you do not have it for either of these, you must secure a copy of the source code. If you have FTP access, you can get MS-DOS source code from wsmr-simtel20.army.mil (File PD1:UUDECODE.PAS). If not, you will have to get it from someone else. Also, you need an archive extractor. Small extract-only programs are available, such as BOOZ by Rahul Dhesi. It will be assumed you can secure one of these without problem, as with uudecode. Also available is the CBIP Starter's Kit, which contains BASIC and DEBUG source for uudecode, a uuencoded version of BOOZ (ZOO file extractor), and instructions on how to make use of these files. This is enough to get you started in dealing with the comp.binaries.ibm.pc newsgroup on UseNet. III. USING UNIX TO DO THE WORK UseNet is a network comprising mostly of UNIX-based machines, so therefor it is quite common to use the system connected to UseNet to do most of the work, rather than downloading from that system and doing all the work on a PC. To do this, you will need the following basic utilities: uudecode editor (vi, emacs, etc.) cat (not necessary, but useful) combine (Also not necessary, but makes everything easy) The first thing you must do is use your news reader program to save the articles to files. If the uuencoded file spans more than one article, save then to different articles. Check your manual pages for the news reader you have for details. If you are using 'rn', do the following: From within the article, or at the end of the article, type 'w filename'. Answer 'n' to the mailbox format question, and then continue. 's filename' could also be used, but it saves additional header information that is not needed, and would have to be edited out anyway. For one single file, things are easy. Use your favorite editor and delete all lines before the 'begin' line, and all lines after the 'end' line. Then you can give the command 'uudecode file', and the new file will be created for you. Download the new file to your PC. For multiple files, you must edit each file. For the first file, delete all lines before the 'begin', and go to the end of the file. A line of uuencoded text looks like this: M'YV01N2\:0-BSAPV: You should then end up with the program you went through all the trouble for. V. HANDLING ARCHIVE FILES An archive is simply a file containing several other files. Usually these other files are compressed in some fashion, in order to save disk space. These files are used generally for easier handling of several files. There are many types currently in existence, such as .ARC, .ZOO, and .ZIP. The instructions below can be used for most any type of archive, using the appropriate programs. To extract files from an ZOO file, you must have some sort of extractor. BOOZ from Rahul Dhesi (to be included in Starter's Kit) is an extract-only program for dealing with ZOO files. The ZOO program itself (also by Rahul Dhesi) can be used to both create and extract ZOO archives. To unpack an entire archive, simply type one of the following: zoo -extract booz x This will unpack the entire contents into the current directory. You need not specify the .ZOO extension. To extract particular files, simply specify the filename after the archive name. VI. DOWNLOADING FILES FROM UNIX TO MSDOS To download the files, you will need the following: 1) A file transfer protocol on your UNIX system (i.e. Kermit, Xmodem, Zmodem, etc.) 2) A PC communications package that supports the same protocol Due to the large amount of protocols and communications packages available, it would be next to impossible to describe all of them. choosing the proper set up often depends on your situation. Some protocols are much faster than others, yet cannot be used over some networks. For the purposes of examples, I will use Kermit as the protocol (specifically C-Kermit), and ProComm as the communications package, as they are in wide use and very reliable over most networks. A more generic method for downloading follows afterwards, but you must read the manuals to all programs to operate them properly. First off is to determine what type of file you are downloading, whether it is binary or ASCII. Usually, if you can read it, it's ASCII. Files with extensions EXE, COM, and archive files such as ZOO are almost always binary. On UNIX, you can say: file this will usually tell you what type of file it is. Downloading ASCII text is easy. On UNIX type: kermit -s the "-s" puts C-Kermit into "send" mode. You then instruct your terminal program to receive a Kermit transfer. On ProComm, you would hit PgDn, and then select Kermit off the menu, selection 2. ProComm will take care of the rest, and you can watch it's progress. When it's done, ProComm will return you to UNIX. Downloading binary files are a little more difficult. If you can dial in to a UNIX host using 8-bit communications (such as 8-N-1), do so. Sometimes the Login: prompt may look weird, but once the host knows, it will fix itself. If you cannot use 8-bit settings (the host insists on 7 bits to be readable), you may wish to transform the binary file into ASCII, using the uuencode program, downloading as above for normally ASCII files, and uudecoding the file on the PC. If you are able to use 8 bits, on UNIX type: kermit -is the "-is" puts C-Kermit into "send, image" mode. Basically, "tell it like it is". As above, hit PgDn, then 2 and ProComm will do the rest. For a more generic explanation of what to do, here is a step-by-step version of the above, without specifics: 1) Determine what type the file is (ASCII or binary) 2) Initiate transfer on UNIX end. Usually accomplished by executing a program and giving the filename of what you wish to download. If it is a binary file, specify 'binary' or 'image' mode, usually as a switch on the command line. 3) Escape back to the PC, and set for receiving a file using the same protocol as being sent with. Often done by hitting some Hot Key (usually Pg-Dn), and then specifying the protocol you are using. You really should read the manuals to any programs you wish to use for downloading files. Programs change, and they are not all used the same way. If you can't seem to get a program to work, consult someone using the same programs, and see what it might be that you do differently. ----- End Included Message ----- ----- End Included Message ----- ----- End Included Message ----- ----- End Included Message ----- From mentor.cc.purdue.edu!greenejl Wed Apr 1 14:37:07 1992 Return-Path: Received: from 128.210.10.8 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 14:36 PST Received: by mentor.cc.purdue.edu (5.61/Purdue_CC) id AA02529; Wed, 1 Apr 92 17:36:12 -0500 From: greenejl@mentor.cc.purdue.edu (Jonathan Greene) Message-Id: <9204012236.AA02529@mentor.cc.purdue.edu> Subject: Re: Bad files To: CONLEY@uservx.plk.af.mil (CONLEY BOB) Date: Wed, 1 Apr 92 17:36:11 EST Cc: eps@reed.edu (Ensoniq EPS Mailing List) In-Reply-To: ; from "CONLEY, BOB" at Apr 1, 92 7:34 am > + uudecode EPS15.gkh.zip.uue > No end line > + uudecode EPS31.gkh.zip.uue > No end line > + uudecode EPS9.gkh.zip.uue > No end line > + uudecode PD10.gkh.zip.uue etc... This was easily solved for me by adding a return after the line before the end line (it WAS there, just not recognaized). I also made sure there EOF was right after the end line. Then it uudecoded without any problem. I couldn't test the file because I don't have my EPS here, but the transfer and unzipping seems to work. I used the vi editor in UNIX (well, DYNIX) to make the changes. Hope this helps, Jon From psy.uwa.oz.au!scott Wed Apr 1 23:21:29 1992 Return-Path: Received: from 130.95.176.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Wed, 1 Apr 92 23:20 PST Received: by wapsy.psy.uwa.oz.au (5.61+IDA+MU) id AA14793; Thu, 2 Apr 1992 15:19:30 +0800 Date: Thu, 2 Apr 1992 15:19:30 +0800 From: scott@psy.uwa.oz.au (Scott Fisher) Message-Id: <9204020719.AA14793@wapsy.psy.uwa.oz.au> To: eps@reed.edu Subject: Radio Ready. I can't remember if someone already said this but... The MARCH edition of TH has a warning in the THIRD PARTY NEWS section that "Radio Ready" were off the phone and to excercise caution if dealing with them... I knew it looked too goot to be true :-) Scott _______________________________________________________________________________ Scott Fisher [scott@wapsy.uwa.oz] PH: Aus [61] Perth (09) Local (380 3574). _--_|\ N Department of Psychology / \ W + E University of Western Australia. Perth --> *_.--._/ S Nedlands, 6009. PERTH, W.A. v *** ERROR 144 - REBOOT? is a registered trademark of ENSONIQ Corp *** ------------------------------------------------------------------------------- From UK.Sun.COM!Craig.Barnes Thu Apr 2 08:35:47 1992 Return-Path: Received: from 192.9.9.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Thu, 2 Apr 92 08:35 PST Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA01137; Thu, 2 Apr 92 08:35:35 PST Received: from UK.Sun.COM (sunuk) by snail.Sun.COM (4.1/SMI-4.1) id AA21551; Thu, 2 Apr 92 08:35:32 PST Received: from nuksun.UK.Sun.COM by UK.Sun.COM (4.1/SMI-4.1e-UK) id AA06672; Thu, 2 Apr 92 17:35:30 BST Received: from hadrian.uk.sun.com by nuksun.UK.Sun.COM (4.1/SMI-5.0-sec(uk - sec)) id AA16768; Thu, 2 Apr 92 17:35:29 BST Date: Thu, 2 Apr 92 17:35:29 BST From: Craig.Barnes@UK.Sun.COM (Craig Barnes - Sun UK - IR N + SW Group Region) Message-Id: <9204021635.AA16768@nuksun.UK.Sun.COM> To: eps@reed.edu Subject: Atari ST sample transfers or Sun Sparc station 2 I have access to both an Atari ST and a Sun Sparc Station 2. Are there any programs to convert these ftp sample files to EPS format available for either machines. And how do I go about getting such files/programs. Rgds Craig From denial.reed.edu!niski Thu Apr 2 09:43:09 1992 Return-Path: Received: from 134.10.2.65 by reed.edu (/\==/\ Smail3.1.25.1 #25.20) id ; Thu, 2 Apr 92 09:42 PST Received: by denial.reed.edu (/\==/\ Smail3.1.25.1 #25.11) id ; Thu, 2 Apr 92 09:39 PST Message-Id: Date: Thu, 2 Apr 92 09:39 PST From: niski@reed.edu (Joe Niski) Received: by NeXT Mailer (1.62) To: Dave Ruska Subject: Re: FTP formats & more cc: eps@reed.edu OK, OK, here's my ballot - Dave, have you gotten many of these yet? | My vote for eps.reed.edu club leader is: | everyone's favorite Ozzie Psychologist, Scott Fisher Return to: daver@hpgrla.gr.hp.com But Scott hasn't asked for the work! How about a committee of 2-5 volunteers to decide things like file formats & directory structure? i'll volunteer, but i'd like input from the others who have strong opinions about this (and more ftp experience). It looks like i'll be able to find the necessary disk here, but i'm not opposed to moving it elsewhere. Since there are nearly 90 of us on the list, and since several seem to have reasonable opinions on how things should work, i think we sho