From groucho.cs.psu.edu!mchen Sun Aug 23 04:05:35 1992 Return-Path: Received: from 130.203.2.10 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Sun, 23 Aug 92 04:04 PDT Received: from localhost by groucho.cs.psu.edu with SMTP id <2623>; Sun, 23 Aug 1992 07:04:20 -0400 To: eps@reed.edu Subject: EPSUTIL v1.26 --- allows formatting different sectors/track Date: Sun, 23 Aug 1992 07:04:05 -0400 From: Michael Chen Message-Id: <92Aug23.070420edt.2623@groucho.cs.psu.edu> EPSUTIL v1.26 is basically an interim release that lets people with IBM PCs twiddle with nonstandard disk formats (like 9 sectors/track). Now that I've got that working, I'm going to properly implement support for the GKH format. Please note (for those programmers fiddling with GKH) that I also intend to include support for the Intel/Motorola flag (it only matters for the tag fields anyway) so that others will have an easier time porting my code. These funky disks are done properly (none of this bad-sector B.S.), and the EPS treats them the same as any other. (As proof, I booted my EPS off a 9 s/t floppy which had the OS copied to it via the COPY OS TO DISK command on the EPS itself.) For those who are porting my code... PLEASE wait for me to implement full GKH support, because it will make most of these problems go away (some kind soul can start reading the 800K images and (on the EPS) doing file-by-file copies to 9 s/t disks, then upload those versions...) I would suggest tagging disk images that are not standard 10-sector disks with .9sctr flags (example: pd16.9sctr.gkh), and maybe making a separate subdirectory on nextweek for them. The EUI format's days are numbered; I intend to create an extension of GKH which does the unused-skip thing, but still uses the GKH header (maybe GK2 or something). That way, I'll be able to compress funky formats, too. Also in the works eventually is the file system... the idea is to encode a disk as its device block, OS sector, and files (including directories). I'll have to make provisions for path names of files, but this is still vaporware at this point; I can dream, can't I? _____________________________________________________________________________ | Michael Chen | From the depths of our most lucid horrors | | | spring our fond hopes and pure desires... | | mchen@groucho.cs.psu.edu | except what comes from HELL! :-) 7/23/92 | \_______________________________\___________________________________________| From nwnexus.wa.com!sounds!brianw Sun Aug 23 12:43:53 1992 Return-Path: Received: from 192.135.191.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Sun, 23 Aug 92 12:42 PDT Received: by nwnexus.wa.com id AA13413 (5.65c/IDA-1.4.4 for reed.edu!eps); Sun, 23 Aug 1992 12:42:46 -0700 Received: by sounds (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA04505; Sun, 23 Aug 92 11:47:29 PDT Date: Sun, 23 Aug 92 11:47:29 PDT From: sounds!brianw@nwnexus.wa.com (Brian Willoughby) Message-Id: <9208231847.AA04505@ sounds > Received: by NeXT Mailer (1.63) To: Michael Chen Subject: Re: EPSUTIL v1.26 --- allows formatting different sectors/track Cc: eps@reed.edu Good work, Michael. | These funky disks are done properly (none of this bad-sector B.S.), | and the EPS treats them the same as any other. (As proof, I booted my EPS | off a 9 s/t floppy which had the OS copied to it via the COPY OS TO DISK | command on the EPS itself.) That is good news. Thanks for verifying that it works on the EPS and reporting it to the list. Did you test this on a Classic or a 16plus? Perhaps I'll finally be able to trade EPS sounds with you folks using my NeXT floppy. | For those who are porting my code... PLEASE wait for me to implement | full GKH support, because it will make most of these problems go away | (some kind soul can start reading the 800K images and (on the EPS) | doing file-by-file copies to 9 s/t disks, then upload those | versions...) I would suggest tagging disk images that are not | standard 10-sector disks with .9sctr flags (example: | pd16.9sctr.gkh), and maybe making a separate subdirectory on | nextweek for them. I'm concerned about the longer file names, but I don't think that it matters for the people who will need 9-sector images. From what I am aware of, only the Mac, NeXT, and Sun or other Unix machines will need to use 9-sector floppies - and these machine all support long file names. Does anyone have a problem with long names? The PC is the only limited file system I can think of, but there are plenty of utilities to handle the 10-sector floppies for DOS systems. If long names are not a problem for anyone, then they would help prevent accidental downloads of the wrong format. At first, I thought that the names should be kept the same, but that each type of file should be stored in a different directory (so that the directory name indicated the number of sectors). But then I realized that mistakes are made easily, and a file might find its way into the wrong directory. For this reason, I agree that there should be an extension. | The EUI format's days are numbered; I intend to create an extension of | GKH which does the unused-skip thing, but still uses the GKH header | (maybe GK2 or something). That way, I'll be able to compress funky | formats, too. Perhaps you could keep the same .GKH extension and just change Tag field 2 in the file's header. I thought that the whole advantage of the GKH format (over a raw disk image without a header) was that it could be expanded in the future to support different schemes. I just read through the GKH specification, so I noticed that it already encodes the number of sectors on the disk. You could just change the value for "number of sectors per track". Utility programs for systems which cannot handle 10-sector disks would just print an error message. Systems which can handle 10-sector disks should be able to automatically support 9-sector formats without any user input (although the existing utilities would have to be coded to handle both cases). Ideas or comments? --- Brian Willoughby Software Design Engineer, BSEE BrianW@SoundS.WA.com SoundSoftware NeXTmail welcome From rigel.cs.pdx.edu!tauren Sun Aug 23 13:37:47 1992 Return-Path: Received: from 131.252.20.103 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Sun, 23 Aug 92 13:36 PDT Received: from rigel.cs.pdx.edu by pdxgate.cs.pdx.edu (4.1/pdx-gateway-evision: 1.27 id AA10018; Sun, 23 Aug 92 13:36:13 PDT Received: from rigel.cs.pdx.edu by rigel.cs.pdx.edu (4.1/pdx-client-evision: 1.17 id AA29855; Sun, 23 Aug 92 13:36:11 PDT Message-Id: <9208232036.AA29855@rigel.cs.pdx.edu> To: eps@reed.edu Subject: Help decipher a MIDI event Date: Sun, 23 Aug 92 13:36:10 PDT From: tauren@rigel.cs.pdx.edu I finally connected my PC to my EPS-16+ and have downloaded the shareware program WinJammer from ftp.cica.indiana.edu. It looks to be a nice Windows sequencer. So everything is now working, but I have a small problem when I load the file MIN-G.MID. I get the EPS set up with four instruments on 1-4 and set it to MULTI mode. But when I press play on WinJammer, the EPS starts playing instruments 1, 3, and 4, and starts loading the 8th instrument on whatever disk is in the EPS into instrument 2. So this sequence must have a LOAD INSTRUMENT code or something. What should I look for? I obviously don't know too much about this yet and the only reference I have is the back of the EPS manual. So I appreciate any help. Thanks, Tauren P.S. This note is to Michael Chen. I've tried sending mail to (mchen@groucho.cs.psu.edu) but I keep having it bounce back to me after 3 days of timing out. I just wanted to let you know that I can't get EPSUTIL to work on my Compaq 386/33. It seems to format fine and write and image to disk, but when I get home and put the disk in my EPS, the EPS says "Disk Not Formatted". I've not seen this message before, only "BAD DEVICE ID". And when I take a freshly EPS-formatted disk to work to try to write an image to it, It doesn't work either (I can't remember the message right now) I have not played with the program's parameters. Do you have any suggestions? Thanks. From groucho.cs.psu.edu!mchen Sun Aug 23 15:31:24 1992 Return-Path: Received: from 130.203.2.10 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Sun, 23 Aug 92 15:30 PDT Received: from localhost by groucho.cs.psu.edu with SMTP id <2677>; Sun, 23 Aug 1992 18:30:06 -0400 to: sounds!brianw@nwnexus.wa.com (Brian Willoughby) cc: Michael Chen , eps@reed.edu, mchen@groucho.cs.psu.edu Subject: Re: EPSUTIL v1.26 --- allows formatting different sectors/track In-reply-to: Your message of "Sun, 23 Aug 92 14:47:29 EDT." <9208231847.AA04505@sounds> Date: Sun, 23 Aug 1992 18:29:56 -0400 From: Michael Chen Message-Id: <92Aug23.183006edt.2677@groucho.cs.psu.edu> Yes, I am aware of the tag in the GKH spec. Actually, in the code fragment that he sent me, type 02 was reserved for FAT_ENTRY, which I assume means the same type of "compression" that the EUI format takes advantage of. Actually, I might use a generalization of the EUI format and declare it as type 03 or such. As it is, the EUI format starts off with the user block (block 0, usually empty unless someone puts data there). The next components are the device entry, the OS entry, the root directory, and the compressed FAT. It occurs to me that I can simply read the sectors per track value and the like from the device entry in the same way the sector editor in v1.26 of EPSUTIL scans the disk. Then, the number of FAT entries can be computed, and after that the code is the same. Hmm, that's an attractive option! Maybe the EUI format isn't dead after all ... maybe I could code a feature where the write to disk routine would check the disk format and reformat if necessary. I could also use the GKH format and add my own type code to it. But all I would really gain is the subject and author fields... the rest of the data contained in the tags is encoded in the file itself anyway, except for the disk type (which is always EPS anyway) and the dump type (for which EUI would have its own entry). Questions? Comments? Insights? Don't be shy... this could be important, as the results of this discussion will likely be ported to other platforms. All opinions, novice or otherwise, are welcome. _____________________________________________________________________________ | Michael Chen | From the depths of our most lucid horrors | | | spring our fond hopes and pure desires... | | mchen@groucho.cs.psu.edu | except what comes from HELL! :-) 7/23/92 | \_______________________________\___________________________________________| From groucho.cs.psu.edu!mchen Sun Aug 23 17:22:53 1992 Return-Path: Received: from 130.203.2.10 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Sun, 23 Aug 92 17:21 PDT Received: from localhost by groucho.cs.psu.edu with SMTP id <2680>; Sun, 23 Aug 1992 20:21:38 -0400 To: eps@reed.edu Subject: EPSUTIL v1.30 --- fully supports weird formats (port this!?!) Date: Sun, 23 Aug 1992 20:21:35 -0400 From: Michael Chen Message-Id: <92Aug23.202138edt.2680@groucho.cs.psu.edu> EPSUTIL v1.30 now supports read and writes of both raw images (.IMG) and .EUI files to weird disk formats -- that is to say, formats other than 10 sectors per track. That being the case, this is the first version of EPSUTIL that is really suited to porting for other machines! One gotcha in porting it is the Intel/Motorola data format problem. But a few patches to the code will take care of that. The .EUI format has been expanded to allow for different formats; old .EUI files will work just fine. The device information stored in the .EUI file is checked against the disk format; if they're not identical, it's a no-go. The same has been done for .IMG files. The file size is checked against the size of the disk being written to; if they clash, no dice. The verify routine no longer checks out to 10 sectors, but actually reads the drive information off the disk. (This is to facilitate using 9-sector disks.) Let me know what you think. I'll work on a Sparc version in my spare time. Until then, I think I'll upload the 9- and 10-sector .EUI files of the latest EPS Classic OS (2.49) to the net. (Why hasn't anyone done the same for the 16 Plus? Why doesn't Ensoniq upload beta versions for us to test en masse?) Enjoy! And send me stuff... gratuities, sound disks, old 2x expanders, ... BMWs... :-) _____________________________________________________________________________ | Michael Chen | From the depths of our most lucid horrors | | | spring our fond hopes and pure desires... | | mchen@groucho.cs.psu.edu | except what comes from HELL! :-) 7/23/92 | \_______________________________\___________________________________________| P.S. How does one try to get a job with the big E, anyway? From groucho.cs.psu.edu!mchen Sun Aug 23 18:01:11 1992 Return-Path: Received: from 130.203.2.10 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Sun, 23 Aug 92 18:00 PDT Received: from localhost by groucho.cs.psu.edu with SMTP id <2680>; Sun, 23 Aug 1992 20:59:55 -0400 To: eps@reed.edu Subject: A note about the uploaded EUIs Date: Sun, 23 Aug 1992 20:59:44 -0400 From: Michael Chen Message-Id: <92Aug23.205955edt.2680@groucho.cs.psu.edu> For the astute: Yes, the OS249-10S EUI file is bigger than the GKH one. But realize that there are 16 2-block MIDI instruments and 2 banks on that disk, too. The OS249-9S EUI file is just the OS itself, and as expected, it's a few K smaller after compression with compress or zip. (It's a LOT smaller when they are both uncompressed.) Zip works better than compress (the first observation). Second, if EPSUTIL gets ported, will people start using the EUI format instead? _____________________________________________________________________________ | Michael Chen | From the depths of our most lucid horrors | | | spring our fond hopes and pure desires... | | mchen@groucho.cs.psu.edu | except what comes from HELL! :-) 7/23/92 | \_______________________________\___________________________________________| From physics.su.OZ.AU!studer Mon Aug 24 00:36:29 1992 Return-Path: Received: from 129.78.129.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 00:35 PDT Received: from alfven.physics.su.OZ.AU by physics.su.OZ.AU (5.61+IDA+MU/1.34) id AA02224; Mon, 24 Aug 1992 17:35:12 +1000 Received: by alfven.physics.su.OZ.AU (4.1/5.17) id AA17195; Mon, 24 Aug 92 17:35:10 EST Date: Mon, 24 Aug 92 17:35:10 EST From: studer@physics.su.OZ.AU (Andrew Studer) Message-Id: <9208240735.AA17195@alfven.physics.su.OZ.AU> To: eps@reed.edu Subject: OK, I'm lost... There's a lot of people going to a lot of effort writing a lot of software out there... I sort of give it all a bit of a cursory read and then get onto other stuff, so if I'm missing a few major bits, please inform me: 1) Why do we now have two disk formats? What is wrong with the old GKH system? Are there any space advantages? When I see EPS disks compress down to 500k or so, I find it hard to believe that they could compress so much more. 2) What it is- exactly- that EPSUTIL can do that epsread and epswrite can't. As I say, I'm getting snowed under with bug fixes and updated. Can someone give us a nice short state-of-the-nation summary telling us what how and why? As I say, this list has been very busy recently, and hoorah to all of those who are putting all this effort in. But please, a CONCISE explanation. Thanks... Andrew Studer... studer@physics.su.oz.au :w From groucho.cs.psu.edu!mchen Mon Aug 24 02:17:33 1992 Return-Path: Received: from 130.203.2.10 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 02:16 PDT Received: from localhost by groucho.cs.psu.edu with SMTP id <2683>; Mon, 24 Aug 1992 05:16:11 -0400 To: studer@physics.su.OZ.AU (Andrew Studer) cc: eps@reed.edu, mchen@groucho.cs.psu.edu Subject: Re: OK, I'm lost... In-reply-to: Your message of "Mon, 24 Aug 92 18:35:10 EDT." <9208240735.AA17195@alfven.physics.su.OZ.AU> Date: Mon, 24 Aug 1992 05:16:06 -0400 From: Michael Chen Message-Id: <92Aug24.051611edt.2683@groucho.cs.psu.edu> Okay. A relatively concise summary of the EPSUTIL saga... EPSUTIL started out as an attempt to do anything at all with EPS disks. Since I'm poor, I can't afford to buy EDM, so I figured I'd write my own. The end result is EPSUTIL. The utilities are for the IBM PC family of computers (basically because that's what I own). As of version 1.30 (the latest), the program lets you: * read and write disk images, both raw (all 819200 bytes, or whatever size) and EUI, which is basically a dump of the used sectors on a disk, as marked in the FAT. * verify EPS disks * format EPS disks * sector edit/browse EPS disks (uses 43-line mode, EGA/VGA required) What does it do that epsread and epswrite don't? Verify, format, and sector edit. It doesn't do the FAT-compressed disk images, either, but if you use a compressor like zip or unix compress, that's not so bad. The other major thing it does that epsread and epswrite doesn't (as of the newest version) is allow the user to do all of those functions to disks that are not necessarily 10-sector disks. For example, I created a 9-sector (that's per track, of course) boot disk for my EPS Classic, and it works fine. That's not a big deal for PC users (due to both my program and Goh King Hwa) or Atari ST types (kudos to Steve Quartly) because utilities to use 10-sector disks exist. But for the normal Mac user, for instance, the 10-sector thing seems to be impossible. Thus the support for different formats --- it allows the possibility of disk trading to those who can't write 10-sector disks. Granted, EPSUTIL does not currently support the GKH format. But it will, if you give me enough time to get to it. It's written entirely in C, so porting the code to other systems (except for the format routines) shouldn't take too much work. I wrote a stupid little program called GKH2IMG a while back which chopped the first 58 bytes off of a GKH file. I really regret that choice, now that I have documentation on the GKH file format. Maybe I'll write a proper one... Basically, it will work on any GKH file without a subject or author field. But I can do better, with the GKH info. Goh King Hwa sent me a copy of his source for his utilities, but there is enough of a difference between my code and his for me to adapt his ideas rather than just using the code verbatim. I apologize for the many versions of the code, but when I code a new useful feature, I usually upload the code. I guess I'll cut back on that now, and only upload when something big happens (next is probably GKH). Did I answer everything? _____________________________________________________________________________ | Michael Chen | From the depths of our most lucid horrors | | | spring our fond hopes and pure desires... | | mchen@groucho.cs.psu.edu | except what comes from HELL! :-) 7/23/92 | \_______________________________\___________________________________________| From dacnet.com!tom Mon Aug 24 07:14:16 1992 Return-Path: Received: from 134.10.2.61 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 07:12 PDT Received: from 192.77.177.1 by itchy.reed.edu (/\==/\ Smail3.1.25.1 #25.23) id ; Mon, 24 Aug 92 07:12 PDT Message-Id: Received: by stubby.dacnet.com (16.6/16.2) id AA29308; Mon, 24 Aug 92 10:05:15 -0400 From: Tom Roehl Subject: 9-sector versus 10-sector To: eps@reed.edu Date: Mon, 24 Aug 92 10:05:13 EDT X-Mailer: ELM [version 2.3 PL0] On this whole issue of which format to archive, I think we should always submit files as normal 10-sector/track images. Utilities on computers that need to read/write 9 sector/track images will have to convert the files before they are processed. We need to define one standard format and stick to it. From whitefish.rtsg.mot.com!macenski Mon Aug 24 08:02:52 1992 Return-Path: Received: from 129.188.136.100 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 08:00 PDT Received: from rtsg.mot.com ([136.182.254.10]) by pobox.mot.com (4.1/SMI-4.0) id AA17301; Mon, 24 Aug 92 09:58:44 CDT Received: from catfish5.. by rtsg.mot.com (4.0/SMI-4.1) id AA17048; Mon, 24 Aug 92 09:58:25 CDT Date: Mon, 24 Aug 92 09:58:23 CDT From: macenski@whitefish.rtsg.mot.com (Charles D. Macenski) Message-Id: <9208241458@catfish5> To: eps@reed.edu Subject: Re: 9-sector versus 10-sector My 2 cents on this issue is that we do not need any more formats. Personally, I think we should convert everything to the Giebler format (my opinion here, no flames requried). Short of that, adding more formats is simply going to make it more difficult to exchange samples. My opinion, Chuck Macenski From uservx.plk.af.mil!CONLEY Mon Aug 24 08:42:41 1992 Return-Path: Received: from 129.238.32.4 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 08:40 PDT Message-Id: Date: 24 Aug 92 09:36:00 MST From: "CONLEY, BOB" Subject: Runaway options To: "eps" >From a recent post by Mike Chen: > EPSUTIL v1.30 now supports read and writes of both raw images (.IMG) and >.EUI files to weird disk formats -- that is to say, formats other than 10 >sectors per track. That being the case, this is the first version of EPSUTIL >that is really suited to porting for other machines! . . . . . . . . . > Let me know what you think. I'll work on a Sparc version in my spare time. >Until then, I think I'll upload the 9- and 10-sector .EUI files of the latest >EPS Classic OS (2.49) to the net. (Why hasn't anyone done the same for the 16 >Plus? Why doesn't Ensoniq upload beta versions for us to test en masse?) I think the scope of these utilities is getting a bit too complicated, and poses the danger that divergent disk formats will make sample trading too difficult and confusing. This seems especially the case for 9 S/T in addition to standard 10 S/T floppies, .GKH files, .EUI files, possibly merged .GKH and .EUI headers, and so on. We seem to be going the same way as file archiving/compressing with .Z, .ZOO, .ZIP, .ARC, .ARJ, ... (sometimes with incompatible versions, so you need to keep tracking down the LATEST version to decode your latest acquired file). Perhaps I am just too old fashioned, but galloping options usually turns into too much work sooner or later. As for me, I simply keep bit-identical images of EPS files on hard disk, or archived to HD floppy with my favorite PC archiver (and I only use one). No headers with INTEL flags, sectors/track flags, is-this-a-GKH-or-EUI-header flags, etc. Just nude images of EPS floppy disks. The hardest part of being a prolific programmer is keeping it SIMPLE when it is so easy to make it complicated! Thanks for soliciting opinions. Bob From uservx.plk.af.mil!CONLEY Mon Aug 24 09:09:16 1992 Return-Path: Received: from 129.238.32.4 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 09:08 PDT Message-Id: Date: 24 Aug 92 09:59:00 MST From: "CONLEY, BOB" Subject: At long last, SYSEX To: "eps" Hello all, I had mentioned in a previous posting a week ago that I had received the latest SYSEX information from Ensoniq. Specifically, the Ensoniq EPS-16 PLUS Digital Sampling Workstation External Command Specification, 27 Jul 1992 revision. I have had time to do a general review of this document, comparing it to the previous revision, and it appears to correct the discrepancies from the previous document. In particular, section 9 (Parameter Numbers) is considerably different in a number of areas. I have yet to cross check the contents of section 9 with the data I had collected a year ago by actually capturing and cataloging the EPS data for most of the parameters, but I will do that and report those findings. One new section of the document is especially helpful to those of us working with individual instruments, layers, and wavesamples extracted from EPS floppy disks. Appendix B lays out what appears to be the actual assembly language declarations for the definitions of instrument, layer, pitch table, wavesample envelope, wavesample, and effect. (Curiously, bank is not present.) These definitions were long needed, and are VERY welcome. They clear up completely, or provide important clues to, the nature of the data organization found within EPS 16+ floppy files. In particular, the declarations include descriptions of those mysterious 10 bytes which precede the names of instruments, etc. If you are working in this area, you should definitely request a copy from Ensoniq. This looks to be a major release of accurate information, and I, for one, would like to offer a great big public THANK YOU, ENSONIQ for making the effort to get this corrected document out to the EPS owners who need it. (Bill, could you relay the thanks to the appropriate individuals within Ensoniq??) Ensoniq might also consider posting an electronic form of this document to the net so that it could be immediately available to the mailing list subscribers, or even maintaining the latest revision on nextweek. If Ensoniq would be willing to do that, but has limited personnel to make it happen, I would be willing to supply the manhours necessary to keep the latest document out there. Thanks again, Ensoniq. Bob From groucho.cs.psu.edu!mchen Mon Aug 24 09:39:13 1992 Return-Path: Received: from 130.203.2.10 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 09:38 PDT Received: from localhost by groucho.cs.psu.edu with SMTP id <2621>; Mon, 24 Aug 1992 12:37:49 -0400 To: "CONLEY, BOB" cc: "eps" , mchen@groucho.cs.psu.edu Subject: Re: Runaway options In-reply-to: Your message of "Mon, 24 Aug 92 12:36:00 EDT." Date: Mon, 24 Aug 1992 12:37:34 -0400 From: Michael Chen Message-Id: <92Aug24.123749edt.2621@groucho.cs.psu.edu> I have already conceded the point that there is no point in my exploding the number of formats... if people are willing to wait until I get the chance to implement the GKH format, we'll be back down to one again, and things will be all nice and happy. BTW, since 10-sector still seems to be the consensus standard, does anyone have clever ways to help 9-sector folks out? Breaking disks into their files would work, but I'm not quite there yet... I was thinking of checking if the last 160 blocks were free, and just changing the device data on the disk if it would still fit. About the EUI-in-a-GKH thing... the only difference between the files would be invisible to the user (in the utility's code). But then epsread and eps- write wouldn't work on them. Personally, I am not particularly worried, since epsutil would replace their functionality, but I don't know what that does to diskwizard and others floating around. The only advantage to EUIs is when uncompressed, if the EPS disk isn't all the way full. I don't know what I'm going to do with it, because it's hard to do random access to sectors which aren't actually IN the data file, but I'm going to leave it around for personal use. (For my disks, which have the OS, MIDI instruments and sequences, it makes backups faster and smaller.) The raw disk image you're talking about is what epsutil calls an .IMG file. I assume you're not using epsutil to make them... in any case, the real value of my program (right now) is the formatting, verify and sector editor, not the image transfer. --- Mike From fys.uio.no!t.g.finstad Mon Aug 24 11:07:54 1992 Return-Path: Received: from 129.240.2.50 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 11:06 PDT Received: from ulrik.uio.no by pat.uio.no with local-SMTP (PP) id <01001-0@pat.uio.no>; Mon, 24 Aug 1992 20:06:44 +0200 Date: Mon, 24 Aug 1992 20:06:40 +0200 Message-Id: <9208241806.AAfidibus03368@fidibus.uio.no> Sender: t.g.finstad@fys.uio.no To: eps@reed.edu From: Terje Finstad Subject: Paradoxes of Musical Pitch Just want to turn your attention to an article in the August issue of Scientific American ( who reads it? I don't but this article I have heard about a long time) with the title of the subject line. It is written by Diana Deutch, and discusses the perception of pitch. Perception of musical sounds is of course an important and fascinating topic for sound-engineers,-synthesists so also for eps -sound makers. I guess many on this list are already well into the subject and find it interesting. The Shepard tones are examples always mentioned in this connection. I have made those on computers for demonstrations, but has anyone on the list made the Shepard staircase on the EPS?. ( which seems quite feasible) Has anyone made the Shepard continous rise on an EPS? ( which would probably have to be an approximation? ) From nwnexus.wa.com!sounds!brianw Mon Aug 24 12:09:27 1992 Return-Path: Received: from 192.135.191.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 12:08 PDT Received: by nwnexus.wa.com id AA02798 (5.65c/IDA-1.4.4 for reed.edu!EPS); Mon, 24 Aug 1992 12:08:05 -0700 Received: by sounds (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA06686; Mon, 24 Aug 92 11:52:48 PDT Date: Mon, 24 Aug 92 11:52:48 PDT From: sounds!brianw@nwnexus.wa.com (Brian Willoughby) Message-Id: <9208241852.AA06686@ sounds > Received: by NeXT Mailer (1.63) To: EPS@reed.edu (EPS Mailing List) Subject: At long last, SYSEX I would like to second Bob Conley's thank you to Ensoniq. I have the May 8, 1992 EPS External Command Specification, which is NOT for the 16 plus. It is for the EPS Classic and also has the helpful, detailed assembly language structure descriptions. I cannot say if it is as up-to-date as the July 1992 version for the 16plus which Bob reviewed, but I can say that anyone programming computer interfaces for the EPS Classic should request this document. | If you are working in this area, you should definitely request a copy | from Ensoniq. This looks to be a major release of accurate | information, and I, for one, would like to offer a great big public | | THANK YOU, ENSONIQ | | for making the effort to get this corrected document out to the EPS | owners who need it. --- Brian Willoughby Software Design Engineer, BSEE BrianW@SoundS.WA.com SoundSoftware NeXTmail welcome From ecn.purdue.edu!davisonj Mon Aug 24 12:35:09 1992 Return-Path: Received: from 128.46.128.59 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 12:33 PDT Received: by en.ecn.purdue.edu (5.65/1.32jrs) id AA21367; Mon, 24 Aug 92 14:33:55 -0500 From: davisonj@ecn.purdue.edu (John M Davison) Message-Id: <9208241933.AA21367@en.ecn.purdue.edu> Subject: Re: Paradoxes of Musical Pitch To: eps@reed.edu Date: Mon, 24 Aug 92 14:33:53 EST X-Mailer: ELM [version 2.3 PL11] > I have > made those on computers for demonstrations, but has anyone on the list made > the Shepard staircase on the EPS?. ( which seems quite feasible) Has > anyone made the Shepard continous rise on an EPS? ( which would probably > have to be an approximation? ) This probably doesn't count, but I sampled the falling Shepard tone sound that appears at the beginning of the second movement of the "Little Boy" suite (I forget the actual titles...sorry) that is on the Jean-Claude Risset CD on the Wergo Computer Music label. By appropriately looping the thing, you could get a (fairly) seamless continuously-descending Shepard tone. So I didn't "make" it, but I ended up with one. davisonj From hub.ucsb.edu!cosmo%cs Mon Aug 24 12:51:00 1992 Return-Path: Received: from 128.111.24.40 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 12:49 PDT Received: from cherry (cherry.ucsb.edu) by hub.ucsb.edu; id AA22399 sendmail 4.1/UCSB-2.0-sun Mon, 24 Aug 92 12:49:54 PDT for eps@reed.edu Message-Id: <9208241949.AA22399@hub.ucsb.edu> Received: from by cherry (4.0) id AA00296; Mon, 24 Aug 92 12:49:48 PDT Date: Mon, 24 Aug 92 12:49:48 PDT From: Burtin Posted-Date: Mon, 24 Aug 92 12:49:48 PDT To: eps@reed.edu Subject: What's up with altosax? I just got back from a 2-month vacation. I tried to log into altosax and was denied access. Are the EPS archives there still up? - Boris (cosmo@cs.ucsb.edu) From fys.uio.no!t.g.finstad Mon Aug 24 13:25:08 1992 Return-Path: Received: from 129.240.2.50 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 13:24 PDT Received: from ulrik.uio.no by pat.uio.no with local-SMTP (PP) id <02785-0@pat.uio.no>; Mon, 24 Aug 1992 22:24:01 +0200 Date: Mon, 24 Aug 1992 22:23:57 +0200 Message-Id: <9208242023.AAfidibus03618@fidibus.uio.no> Sender: t.g.finstad@fys.uio.no To: eps@reed.edu From: Terje Finstad Subject: Re: What's up with altosax? >I just got back from a 2-month vacation. I tried to log into altosax and >was denied access. Are the EPS archives there still up? > try again nextweek From dacnet.com!tom Mon Aug 24 13:57:17 1992 Return-Path: Received: from 192.77.177.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 13:55 PDT Message-Id: Received: by stubby.dacnet.com (16.6/16.2) id AA05757; Mon, 24 Aug 92 16:55:39 -0400 From: Tom Roehl Subject: Re: What's up with altosax? To: eps@reed.edu (Ensoniq Mailing List) Date: Mon, 24 Aug 92 16:55:37 EDT X-Mailer: ELM [version 2.3 PL0] > From: Terje Finstad > Subject: Re: What's up with altosax? > > >I just got back from a 2-month vacation. I tried to log into altosax and > >was denied access. Are the EPS archives there still up? > > > try again nextweek > Terje's attempt at a joke will no doubt be misunderstood. The name of the altosax archive has been changed to nextweek.reed.edu. I would have replied directly, but I did not save the address of the original poster. From swamp.cis.ufl.edu!mas Mon Aug 24 14:39:46 1992 Return-Path: Received: from 128.227.176.10 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 14:38 PDT Received: by swamp.cis.ufl.edu (5.61ufl/4.12) id AA05863; Mon, 24 Aug 92 17:38:41 -0400 Date: Mon, 24 Aug 92 17:38:41 -0400 From: "Mark Schneider" Message-Id: <9208242138.AA05863@swamp.cis.ufl.edu> To: eps@reed.edu Subject: sounds.wa.com A while back, someone mentioned a sample site. The address they gave was "sounds.wa.com" with IP address "192.135.191.1". My unix's nslookup command says the IP address for sounds.wa.com is "192.135.191.103". Neither sounds.wa.com nort 192.135.191.103 responds. 192.135.191.1, however, allows anonymous ftp, but doesn't appear to have anything to do with midi or music. Does anyone know if the name changed? ------------------------------------------------------------------------------- | Mark | | mas@cis.ufl.edu | | 904-335-6511 (voice) | ------------------------------------------------------------------------------- From physics.su.OZ.AU!studer Mon Aug 24 16:00:18 1992 Return-Path: Received: from 129.78.129.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 15:59 PDT Received: from alfven.physics.su.OZ.AU by physics.su.OZ.AU (5.61+IDA+MU/1.34) id AA07718; Tue, 25 Aug 1992 08:58:46 +1000 Received: by alfven.physics.su.OZ.AU (4.1/5.17) id AA17817; Tue, 25 Aug 92 08:58:45 EST From: studer@physics.su.OZ.AU (Andrew Studer) Message-Id: <9208242258.AA17817@alfven.physics.su.OZ.AU> Subject: Re: OK, I'm lost... To: t.g.finstad@fys.uio.no (Terje Finstad) Date: Tue, 25 Aug 92 8:58:42 EST Cc: eps@reed.edu In-Reply-To: <9208241150.AAfidibus02118@fidibus.uio.no>; from "Terje Finstad" at Aug 24, 92 1:50 pm X-Mailer: ELM [version 2.3 PL11] > >As I say, this list has been very busy recently, and hoorah to all of those > >who are putting all this effort in. But please, a CONCISE explanation. > > > > Thank's for your note - > > What I wan't to say which I cannot say appropriatly on the list is > that I (and I think many others) would much rather see discussions > on more eps specific things in a music related or sound generating > context, and on disks -less.( I see that as contained in what you say too > ). > Well, to be honest, no that's not really what I meant. I think that there would be a reasonable proportion of people who are interested in all this stuff- people with Macs who want to download stuff for example. But, you see, before Michael Chen's explanation, I'd missed that... Anything that broadens the user base of people who can submit and access sample data has got to be a good thing. I just wanted an overview of what was going on without the technical stuff. A DOS guru I am not (I sort of got lost after the Apple ][ :-), and a simple explanation was what I got. I'm happy now! > I enjoyed your Loop Modulation Letter, Part One > And Part Two was promised in august. Hey, I've actually started writing this one! I'm just getting together some examples and demos. I'm also "pre editing" a version for Transoniq, which , unlike Part One, reads more like a tutorial than a reference manual. > So please get the list onto a better track if you can, > part 2 would certainly contribute- if you have time > Well, let's be fair here: I don't know when you joined the list, but I joined after the GKH standard was established. Looking over the archives, I could sense the excitement as people saw the whole thing come together. There's a bit of that excitement around at the moment, as people are pushing towards getting all this software together. I'm not annoyed at all, but I do have the feeling of "being on the outside" because I'm not one of the dedicated bunch of code writers out there. Mike's summary alleviated that greatly. > Sincerely > Terje Andrew Studer... studer@physics.su.oz.au > From nwnexus.wa.com!sounds!brianw Mon Aug 24 17:55:00 1992 Return-Path: Received: from 192.135.191.1 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 17:53 PDT Received: by nwnexus.wa.com id AA08115 (5.65c/IDA-1.4.4 for reed.edu!eps); Mon, 24 Aug 1992 17:54:00 -0700 Received: by sounds (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA09377; Mon, 24 Aug 92 17:46:40 PDT Date: Mon, 24 Aug 92 17:46:40 PDT From: sounds!brianw@nwnexus.wa.com (Brian Willoughby) Message-Id: <9208250046.AA09377@ sounds > Received: by NeXT Mailer (1.63) To: eps@reed.edu Subject: Re: sounds.wa.com This is my machine! Please don't bother trying to access it to get samples since I have not allowed anonymous ftp (I only have a 400 MB hard disk). Mark is correct: 192.135.191.1 has nothing to do with midi or music, it just happens to be in my domain here in Washington. I was a member of the mailing list long before SoundS was assigned an IP address, but I have not heard anyone mention that it was a sample site. At least this rumor was not distributed to me from the mailing list. P.S. Do we need another sample site?!? | A while back, someone mentioned a sample site. The address they gave | was "sounds.wa.com" with IP address "192.135.191.1". My unix's | nslookup command says the IP address for sounds.wa.com is [...] | responds. 192.135.191.1, however, allows anonymous ftp, but | doesn't appear to have anything to do with midi or music. Does anyone | know if the name changed? --- Brian Willoughby Software Design Engineer, BSEE BrianW@SoundS.WA.com SoundSoftware NeXTmail welcome From mundil.cs.mu.OZ.AU!conway Mon Aug 24 22:31:02 1992 Return-Path: Received: from 128.250.35.21 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Mon, 24 Aug 92 22:29 PDT Received: from mundil.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.64+1.3.1+0.50); id AA20842 Tue, 25 Aug 1992 15:29:47 +1000 (from conway@mundil.cs.mu.OZ.AU) Received: by mundil.cs.mu.OZ.AU (920110.SGI) id AA25241; Tue, 25 Aug 92 15:29:43 +1000 From: conway@mundil.cs.mu.OZ.AU (Thomas Charles CONWAY) Message-Id: <9208250529.25241@mundil.cs.mu.OZ.AU> Subject: Paradoxes of Musical Pitch (fwd) To: eps@reed.edu Date: Tue, 25 Aug 92 15:29:42 EST X-Mailer: ELM [version 2.3 PL11] Hi > Just want to turn your attention to an article in the August issue of > Scientific American ( who reads it? I don't but this article I have heard I do, but the August issue hasn't arrived in Australia yet Thomas -- "In our world", said Eustace, "the sun is a huge ball of flaming gas." "Even in your world", the man replied, "that is not what it is, but only what "it is made of." Motto : AD DEUM ET VINUM email: smail: conway@mundil.cs.mu.oz.au Thomas Conway conway@mullauna.cs.mu.oz.au 34 Ramsay Ave East Kew 3102 (Australia) From hub.ucsb.edu!cosmo%cs Tue Aug 25 17:28:47 1992 Return-Path: Received: from 128.111.24.40 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Tue, 25 Aug 92 17:28 PDT Received: from cherry (cherry.ucsb.edu) by hub.ucsb.edu; id AA01986 sendmail 4.1/UCSB-2.0-sun Tue, 25 Aug 92 17:28:38 PDT for eps@reed.edu Message-Id: <9208260028.AA01986@hub.ucsb.edu> Received: from by cherry (4.0) id AA00368; Tue, 25 Aug 92 17:28:33 PDT Date: Tue, 25 Aug 92 17:28:33 PDT From: Burtin Posted-Date: Tue, 25 Aug 92 17:28:33 PDT To: eps@reed.edu Subject: EPS 16+ OS 1.3 I just called Ensoniq and they said that the new OS 1.3 is already out and that they'd send me a copy. Has anyone else gotten a copy yet? What are the latest and greatest features? Can someone upload it to nextweek? - Boris (cosmo@cs.ucsb.edu) From poda.wins.icl.co.uk!A.Spiceley Wed Aug 26 02:17:26 1992 Return-Path: Received: from 192.91.199.254 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 26 Aug 92 02:17 PDT Received: from eros.uknet.ac.uk by ben.uknet.ac.uk via UKIP with SMTP (PP) id ; Wed, 26 Aug 1992 10:16:57 +0100 X400-Received: by mta eros.uknet.ac.uk in /PRMD=UK.AC/ADMD=GOLD 400/C=GB/; Relayed; Wed, 26 Aug 1992 10:15:59 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; Relayed; Wed, 26 Aug 1992 10:13:29 +0100 X400-Received: by /PRMD=iclexpo/ADMD=gold 400/C=GB/; Relayed; Wed, 26 Aug 1992 10:13:58 +0100 Date: Wed, 26 Aug 1992 10:13:29 +0100 X400-Originator: A.Spiceley@poda.wins.icl.co.uk X400-MTS-Identifier: [/PRMD=iclexpo/ADMD=gold 400/C=GB/;ICLPODA 0000001300006251] X400-Content-Type: P2-1984 (2) Content-Identifier: 6251 From: A.Spiceley@poda.wins.icl.co.uk Message-ID: <"6251*/I=A/S=Spiceley/OU=poda/O=icl/PRMD=iclexpo/ADMD=gold 400/C=GB/"@MHS> To: eps@reed.edu Subject: Falling (Shephard) tones on EPS As described in August Scientific American. Regrettably I no longer have the message, but if I really heard that someone had emulated these continually descending/rising tones on an EPS, could that person explain how it was done (rather than upload the sample/patch to nextweek as I've still got no ftp..)? Thanks. From fl08-g.comm.mot.com!schickda Wed Aug 26 05:20:47 1992 Return-Path: Received: from 129.188.136.100 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 26 Aug 92 05:20 PDT Received: from comm.mot.com ([145.1.3.2]) by pobox.mot.com (4.1/SMI-4.0) id AA09468; Wed, 26 Aug 92 07:18:45 CDT Received: from fl08-g.comm.mot.com (node_27d3b.comm.mot.com) by comm.mot.com (4.1/SMI-4.0) id AA01047; Wed, 26 Aug 92 07:25:23 CDT Received: by fl08-g.comm.mot.com ( 5.52 (84)/5.17) id AA01586; Wed, 26 Aug 92 08:02:46 EDT Message-Id: <9208261202.AA01586@fl08-g.comm.mot.com> From: schickda@fl08-g.comm.mot.com (David Schick) Date: Wed, 26 Aug 92 08:02:42 EDT Subject: Sorry!!?? To: eps@reed.edu Helloooooo! Sorry if eps mail has been bouncing from my address. They had the plant shut down for 2 days due to hurricane Andrew. Here in Ft. Lauderdale it wasn't so bad - some uprooted trees, flooding around the intracoastal; but south Dade county (south of Miami) was really wasted. - Zoltan Android (schickda@fl08-g.comm.mot.com) From fl08-g.comm.mot.com!schickda Wed Aug 26 05:20:54 1992 Return-Path: Received: from 129.188.136.100 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 26 Aug 92 05:20 PDT Received: from comm.mot.com ([145.1.3.2]) by pobox.mot.com (4.1/SMI-4.0) id AA09471; Wed, 26 Aug 92 07:18:49 CDT Received: from fl08-g.comm.mot.com (fcaseg1.comm.mot.com) by comm.mot.com (4.1/SMI-4.0) id AA01050; Wed, 26 Aug 92 07:25:27 CDT Received: by fl08-g.comm.mot.com ( 5.52 (84)/5.17) id AA01586; Wed, 26 Aug 92 08:02:46 EDT Message-Id: <9208261202.AA01586@fl08-g.comm.mot.com> From: schickda@fl08-g.comm.mot.com (David Schick) Date: Wed, 26 Aug 92 08:02:42 EDT Subject: Sorry!!?? To: eps@reed.edu Helloooooo! Sorry if eps mail has been bouncing from my address. They had the plant shut down for 2 days due to hurricane Andrew. Here in Ft. Lauderdale it wasn't so bad - some uprooted trees, flooding around the intracoastal; but south Dade county (south of Miami) was really wasted. - Zoltan Android (schickda@fl08-g.comm.mot.com) From woodbine.csri.toronto.edu!csri.toronto.edu!har Wed Aug 26 07:29:19 1992 Return-Path: <@woodbine.csri.toronto.edu:har@csri.toronto.edu> Received: from 128.100.1.10 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 26 Aug 92 07:29 PDT Received: by woodbine.csri.toronto.edu id <182>; Wed, 26 Aug 1992 10:28:54 -0400 From: Harriet Hume To: eps@reed.edu Subject: Output expander Cc: har@csri.toronto.edu Message-Id: <92Aug26.102854edt.182@woodbine.csri.toronto.edu> Date: Wed, 26 Aug 1992 10:28:52 -0400 I would like to know how useful the Output Expander is for the EPS16+. Does anyone have/use one? Is it worth it? Thanks. HH From ecn.purdue.edu!del Wed Aug 26 10:31:17 1992 Return-Path: Received: from 128.46.129.85 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 26 Aug 92 10:30 PDT Received: by pasture.ecn.purdue.edu (5.65/1.32jrs) id AA11046; Wed, 26 Aug 92 12:30:51 -0500 Date: Wed, 26 Aug 92 12:30:51 -0500 From: del@ecn.purdue.edu (de l`abattoir) Message-Id: <9208261730.AA11046@pasture.ecn.purdue.edu> To: eps@reed.edu Subject: OS 1.3 perhaps mr WAVeBOY could explain what the new OS will, ummm, enhance? danke. -david From ecn.purdue.edu!del Wed Aug 26 10:36:53 1992 Return-Path: Received: from 128.46.129.85 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 26 Aug 92 10:36 PDT Received: by pasture.ecn.purdue.edu (5.65/1.32jrs) id AA11133; Wed, 26 Aug 92 12:36:34 -0500 Date: Wed, 26 Aug 92 12:36:34 -0500 From: del@ecn.purdue.edu (de l`abattoir) Message-Id: <9208261736.AA11133@pasture.ecn.purdue.edu> To: eps@reed.edu Subject: more wish list... adding to the next EPS generation wish list: digital in/out -david From grassman.gvg.tek.com!simpsonn Wed Aug 26 12:31:23 1992 Return-Path: Received: from 128.181.48.11 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 26 Aug 92 12:30 PDT Received: by relay.tek.com id ; Wed, 26 Aug 92 12:22:54 -0700 Received: from gvgpsa.gvg.tek.com by tektronix.TEK.COM (4.1/8.0) id AA04158; Wed, 26 Aug 92 12:26:46 PDT Received: by gvgpsa.gvg.tek.com (5.57/9204230) id AA05634; Wed, 26 Aug 92 12:22:21 PDT Received: by grassman.gvg.tek.com (4.1/SMI-4.1) id AA05312; Wed, 26 Aug 92 12:22:17 PDT Date: Wed, 26 Aug 92 12:22:17 PDT From: simpsonn@grassman.gvg.tek.com (Nanette Simpson) Message-Id: <9208261922.AA05312@grassman.gvg.tek.com> To: eps@reed.edu Subject: problem /w edit pitch Hello. I have an eps-16+ and have been using the edit pitch to lower the key a bit for a couple of numbers. Three times now, I'll be playing along and bango the whole keyboard goes totally out of key! Honest, I was doing Nothing but playing (using the steinway 1500? block instument that comes with the system in each case, I think) and lowering the key of whatever only one whole note. Gads this is scarey! I have a live performance in a month... is my machine broke? )-: ...is this a bug? Anyone else hear of this? Nanette simpsonn@grassman.gvg.tek.com From groucho.cs.psu.edu!mchen Wed Aug 26 12:41:58 1992 Return-Path: Received: from 130.203.2.10 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 26 Aug 92 12:41 PDT Received: from localhost by groucho.cs.psu.edu with SMTP id <2621>; Wed, 26 Aug 1992 15:41:26 -0400 To: simpsonn@grassman.gvg.tek.com (Nanette Simpson) cc: eps@reed.edu, mchen@groucho.cs.psu.edu Subject: Re: problem /w edit pitch In-reply-to: Your message of "Wed, 26 Aug 92 15:22:17 EDT." <9208261922.AA05312@grassman.gvg.tek.com> Date: Wed, 26 Aug 1992 15:41:17 -0400 From: Michael Chen Message-Id: <92Aug26.154126edt.2621@groucho.cs.psu.edu> A thought... did you transpose all of the layers or just one? (I assume the patch uses more than one layer for each note.) To change them all, make sure you see WHATEVER LYR=A WS=ALL when you check the Edit page. --- Mike From kong.gsfc.nasa.gov!arensb Wed Aug 26 13:38:52 1992 Return-Path: Received: from 128.183.115.33 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 26 Aug 92 13:38 PDT Received: from kong.gsfc.nasa.gov by lego.gsfc.nasa.gov (5.61/1.35) id AA08865; Wed, 26 Aug 92 16:37:47 -0400 Received: by kong.gsfc.nasa.gov (4.1/SMI-4.1) id AA29140; Wed, 26 Aug 92 16:37:48 EDT Date: Wed, 26 Aug 92 16:37:48 EDT From: arensb@kong.gsfc.nasa.gov (Andrew Arensburger - RMS) Message-Id: <9208262037.AA29140@kong.gsfc.nasa.gov> To: eps@reed.edu, thomas@sics.se Subject: EPS SysEx library 2.0 on nextweek. I've just uploaded version 2.0.0 of my EPS SysEx library to nextweek.reed.edu , to /pub/incoming . Here is the README file that goes with it: ----- begin included file ---------------------------------------- ===== Introduction This is version 2 of my long-promised EPS System Exclusive routine library. The routines contained in this distribution implement a large subset of the routines found in Ensoniq's "EPS Performance Sampler External Command Specification" and should be useful to anyone writing code to control the EPS via MIDI. This library should be easy to port to just about any reasonable architecture. I welcome any comments. Although I'm not asking for any money for this, I'd appreciate it if you'd drop me a line if you use this code. I can be reached at arensb@kong.gsfc.nasa.gov Disclaimer: this software is distributed without any guarantees whatsoever, either express or implied. In particular, while I have tried to write code that works on a much broader range of hardware and software configurations than what was available to me, in many cases it was impossible for me to test this code. ===== Installation This distribution comes with one pre-compiled library: libeps.a is a GCC library for the Amiga. If you're using GCC, copy 'libeps.a' to lib:, copy the include files to usr:include, and you're ready to go (once you've RTFM, of course). Otherwise, read on. Throughout this distribution, you will find files called 'DMakefile'. These are Makefiles for Matt Dillon's 'DMake' utility. It should be easy to convert them to conventional Makefiles: just rename them to "Makefile" and edit them to suit your system. There are comments throughout, to help you. From the top-level directory, run 'DMake' (or 'make', or whatever) to have it build the library and documentation. If, for some reason, you can't run 'make' or can't adapt the DMakefiles easily to your system, the 'libsrc' directory contains the sources for the library, one function per file (mostly). As for the details of building them into a coherent library, you're on your own. If you're porting this library to a new architecture, read the 'doc/PORTING' file for directions and guidelines. ===== New features Version 2 is a complete ground-up rewrite of version 1. If you have any copies of version 1 lying around, delete them. This version is much nicer. Much, *much* nicer. Features include: - Almost complete implementation of the EPS External Command Specification from Ensoniq. The only functions that haven't been included are the looping functions, since I haven't been able to figure out how to do them entirely via MIDI. - EPS 16+ support. Well, I think it ought to work on a 16+. I only have a Classic to test this on, unfortunately (you _could_, of course, send me a donation to allow me to buy this beast). - Portability. This release contains one (!) system-dependent file: 'libsrc/amiga/midi.c', and a few Amiga-specific fields in 'include/eps.h'. I've tried very hard to make this as portable as possible to just about any system (as a former MS-DOS 3.1 user, I had some idea of what not to expect from an OS :-) ). - Multiple EPSs. You can communicate with several EPSs independently simultaneously. - Provisions for SCSI. Unfortunately, my EPS doesn't have SCSI (yet), but I've planned for the day when it will: none of the library functions assume MIDI as the underlying medium, only the auxiliary functions do; this should make it easy to add SCSI support. - Consistent naming conventions and argument lists. Version 1 of this library suffered from the fact that similar functions did not always have similar argument lists. Version 2 fixes this: all functions are of type 'int', have descriptive names, and take similar argument lists. - Sane return values. Version 1 of this library returned some pretty arbitrary values at times. In particular, start-of-wavesample offsets were represented differently from end-of-wavesample offsets, and neither of them was the same as what the EPS displayed on its front panel. Version 2 eliminates this: all offsets are of the same type, all are normalized to be the same as what the EPS displays, sample values are normalized to 15 bits + sign, and so forth. - Extensive documentation. Each function is documented within its own source code, making it easy to keep functionality and documentation in sync. The Amiga 'autodoc' utility (and my Perl clone thereof) extract the documentation from the source and compile it into a consistent, alphabetized reference document. - Examples. Okay, so there's only two of them. But they should make it easier to get started. ----- end included file ------------------------------------------ This software is freely distributable. The legalese disclaimer at the top of every file is intended only to prevent third parties from tarnishing my reputation by disseminating broken software under my name. I welcome comments, criticisms, bug fixes, and will gladly collaborate with anyone wishing to port this library to another platform. -- ----- Tasteless .sig coming up -------------------------------------------- Andrew Arensburger | But Andrew is no kind and gentle breeze: arensb@kong.gsfc.nasa.gov | Andrew is a HURRICANE! He demands ...!uunet!dftsrv!kong!arensb | SACRIFICE! From wri.com!andre Wed Aug 26 13:59:38 1992 Return-Path: Received: from 140.177.10.12 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 26 Aug 92 13:58 PDT Received: from rurutu.wri.com by dragonfly.wri.com with SMTP id AA04715 (5.65c/IDA-1.4.4 for ); Wed, 26 Aug 1992 15:58:24 -0500 Return-Path: Date: Wed, 26 Aug 92 15:58:23 -0500 From: andre@wri.com Message-Id: <9208262058.AA00251@rurutu.wri.com> Received: by NeXT Mailer (1.63) To: eps@reed.edu Subject: Re: Output expander I use the Output Expander. Yes, it's useful, especially since you can practically cook an egg on it! (heats leftovers just fine). Seriously, it does get awfully hot which worries me some times. It's really the only way you can use the EPS-16's effect patch busses to any degree of flexibility, and allows a little more control in mixdowns if you don't want depend entirely on the sequencer to do things like fades, etc. AK From reef.cis.ufl.edu!mas Wed Aug 26 17:01:05 1992 Return-Path: Received: from 128.227.224.4 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 26 Aug 92 17:00 PDT Received: by reef.cis.ufl.edu (5.61ufl/4.12) id AA13741; Wed, 26 Aug 92 20:00:54 -0400 Date: Wed, 26 Aug 92 20:00:54 -0400 From: "Mark Schneider" Message-Id: <9208270000.AA13741@reef.cis.ufl.edu> To: eps@reed.edu Subject: RE: problem w/ edit pitch > Hello. I have an eps-16+ and have been using the edit pitch to >lower the key a bit for a couple of numbers. Three times now, I'll >be playing along and bango the whole keyboard goes totally out of key! >Honest, I was doing Nothing but playing (using the steinway 1500? block >instument that comes with the system in each case, I think) and lowering >the key of whatever only one whole note. Gads this is scarey! > I have a live performance in a month... is my machine broke? )-: >...is this a bug? Anyone else hear of this? > Why don't use just transpose the whole instrument, instead of each layer. Hit: EDIT, INST and scroll left until you see "TRNS OCT=+0 SEMI=+0" Then change SEMI to whatever you want. From psy.uwa.edu.au!scott Wed Aug 26 20:26:26 1992 Return-Path: Received: from 128.250.1.21 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 26 Aug 92 20:26 PDT Received: from wapsy.psy.uwa.oz.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17990; Thu, 27 Aug 1992 13:26:06 +1000 (from scott@psy.uwa.edu.au) Received: by psy.uwa.edu.au (4.1/SMI-4.1) id AA17411; Thu, 27 Aug 92 11:24:33 WST Date: Thu, 27 Aug 92 11:24:33 WST From: scott@psy.uwa.edu.au (Scott Fisher) Message-Id: <9208270324.AA17411@psy.uwa.edu.au> To: eps@reed.edu Subject: Pitch Problems... >From simpsonn@grassman.gvg.tek.com Thu Aug 27 04:29:00 1992 > > Hello. I have an eps-16+ and have been using the edit pitch to >lower the key a bit for a couple of numbers. Three times now, I'll >be playing along and bango the whole keyboard goes totally out of key! >Honest, I was doing Nothing but playing (using the steinway 1500? block >instument that comes with the system in each case, I think) and lowering >the key of whatever only one whole note. Gads this is scarey! > I have a live performance in a month... is my machine broke? )-: >...is this a bug? Anyone else hear of this? > > Nanette > simpsonn@grassman.gvg.tek.com The first thing that sprang to my mind was... DID YOU HAVE THE EDIT PITCH PAGE SELECTED and WAS THE CURSOR ON THE PITCH COMMAND? ...if so then it is quite possible that you are suffering from nothing more serious than a twitchy data slider. Most EPS/16Plus data sliders get a little finniky after use and will change values of the parameter they are presently set to edit. Simply make sure you are on a page where it cant (the data slider) do anything drastic...ie edit a sound parameter. Regards Scott. _______________________________________________________________________________ Scott Fisher [scott@psy.uwa.oz.au] PH: Aus [61] Perth (09) Local (380 3272). _--_|\ 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 sndcrft.dialix.oz.au!steveq Thu Aug 27 23:40:25 1992 Return-Path: Received: from 128.250.1.21 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Thu, 27 Aug 92 23:38 PDT Received: from uniwa.uwa.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20092; Fri, 28 Aug 1992 16:38:49 +1000 (from steveq@sndcrft.dialix.oz.au) Received: by uniwa.uwa.edu.au (5.65c) id AA17297; Fri, 28 Aug 1992 14:38:46 +0800 Received: from sndcrft.DIALix.oz.au by DIALix.oz.au id aa05512; 28 Aug 92 14:34 WST Received: by sndcrft.DIALix.oz.au (HERMES RMAIL 1.00 Rev. Jan 16 1992) id <0btobky@sndcrft.DIALix.oz.au>; 28 Aug 92 04:12 MET From: steveq@sndcrft.dialix.oz.au (Steve Quartly) Message-Id: Organization: Sound Craft Creative Music Subject: My UUCP died! To: eps@reed.edu Reply-To: steveq@sndcrft.dialix.oz.au X-Software: HERMES GUS 1.00 Rev. Jan 16 1992 Date: Fri, 28 Aug 1992 04:04:50 MET Hi Guys, It seems my previous letter regarding the EUI & other formats was sent a little late as Bob Connley already expressed virtually the exact same views. Sorry, My UUCP connection died & I have been "off air" for several days now. I guess if anything it backs up Bob. Thanks, -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> S t e v e Q u a r t l y, P e r t h W e s t e r n A u s t r a l i a, _--_|\ N PH: Aus [61] Perth (09) Local (309 4445). / \ W + E Perth --> *_.--._/ S 43rd Law of Computing: Anything tha can go wr v error: Segmentation violation -- Core dumped. steveq@sndcrft.DIALix.oz.au <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> From RCNVMS.RCN.MASS.EDU!NLEONARD Sat Aug 29 13:01:26 1992 Return-Path: Received: from 134.241.10.5 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Sat, 29 Aug 92 13:00 PDT Received: from RCNVMS.RCN.MASS.EDU by RCNVMS.RCN.MASS.EDU (PMDF #3065 ) id <01GO5QUY7FZK9I4AD6@RCNVMS.RCN.MASS.EDU>; Sat, 29 Aug 1992 15:57:14 EDT Date: 29 Aug 1992 15:57:14 -0400 (EDT) From: NLEONARD@RCNVMS.RCN.MASS.EDU Subject: 16+ OS 1.30 Bank Load Bug To: eps@reed.edu Message-id: <01GO5QUY7PMQ9I4AD6@RCNVMS.RCN.MASS.EDU> X-VMS-To: IN%"eps@reed.edu" MIME-version: 1.0 Content-transfer-encoding: 7BIT When I send my EPS a program change number that corrosponds to an EPS bank file it locks the eps up. I have installed OS 1.3 on my hard drive , reformated the drive and reinstalled all the files, along with the new OS. Can the new OS be this unreliable? Has anyone tried to do the same. Maybe the bank loading only works from the internal sequencer. Any ideas. k;eI* For those of you who do not have os 1.3, Ensoniq will send it to anyone who calls them free of charge. Thanks in advance for any advice, Neil Leonard nleonard@ecn.mass.edu From ecn.purdue.edu!del Sat Aug 29 13:39:40 1992 Return-Path: Received: from 128.46.129.85 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Sat, 29 Aug 92 13:39 PDT Received: by pasture.ecn.purdue.edu (5.65/1.32jrs) id AA08831; Sat, 29 Aug 92 15:39:26 -0500 Date: Sat, 29 Aug 92 15:39:26 -0500 From: del@ecn.purdue.edu (de l`abattoir) Message-Id: <9208292039.AA08831@pasture.ecn.purdue.edu> To: eps@reed.edu Subject: WAVeBOY effects-in disk these guys are prompt! got the disk 2 days after ordering it. i havent had too much time to look it over, but here are my initial thoughts: there are 16 (i think) stock factory effects that now have the capability to process external input. they seem to work as advertised. it is a shame, though, that when using the external inputs, you really only have one bus left. this means that the external effect can use the "additional" effect, while on most effects, the left-over bus is only reverb (the last bus is usually dry). twood have been nice if the dry bus could have also had an effect on it. most of my sequences had made the most of the two effects busses, and now i am down to one. there are 8 additional effects. among them are some new reverbs and a four-voice pitch shift, which makes for easy harmonies on instruments. a slight bug (maybe, i havent looked into it, just noticed it): on several effects, if the external input is loud (overloading, maybe), the signal completely cuts out and doesnt return until you re-load the effect. seems a little touchy. overall, a nice addition to the library. could someone please explain the updates of the new 16+ O.S? they arent obvious.. -david From fys.uio.no!t.g.finstad Sat Aug 29 18:07:15 1992 Return-Path: Received: from 129.240.2.50 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Sat, 29 Aug 92 18:07 PDT Received: from ulrik.uio.no by pat.uio.no with local-SMTP (PP) id <26446-0@pat.uio.no>; Sun, 30 Aug 1992 03:06:49 +0200 Date: Sun, 30 Aug 1992 03:06:44 +0200 Message-Id: <9208300106.AAfidibus08719@fidibus.uio.no> Sender: t.g.finstad@fys.uio.no To: eps@reed.edu From: Terje Finstad Subject: Re: 16+ OS 1.30 Bank Load Bug Cc: t.g.finstad@fys.uio.no Sorry if this is a repost but I got a rebounce different from the usual one Neil Leonard writes: >When I send my EPS a program change number that corrosponds to an EPS >bank file it locks the eps up. I have installed OS 1.3 on my hard drive >, reformated the drive and reinstalled all the files, along with the >new OS. Can the new OS be this unreliable? > >Has anyone tried to do the same. Maybe the bank loading only works from the >internal sequencer. Any ideas. k;eI* > I know nothing about this so I answer hoping to find out. How did you save those Banks onto the hard drive? ( copy/restore?) I think that if you had loaded them into memory from their original source, ( floppy or another hard disk ) and then saved a (new) Bank (together with the instruments or visa versa) to your hard disk that may not lock your EPS up. I think this is because the Bank file is a file with references to other files, if those files have changed ( their adress location ) then there is trouble. How is it normally, can you have the instruments making up a bank residing in different directories? Could you even have them (the instruments) reside on different hard disks of a SCSI chain and the thing would work as long as you keep the instruments in the same place as when you loaded them and saved them to a bank? A comment: I am a little disappointed that the OS don't find out that something is wrong and give a message instead of just locking up. But as with the other specialties with Ensoniq equipment: it feels good to hear other people having the same problems. ; ) Some related questions: Does the Ensoniq Disk Manager support banks? - As movable linked objects of songs and instruments? I have these files-now-what do I do with them? I have a bank file and the associated instruments spread out over two disks. Is that a common situation? and I have not seen it before? thats my guess tgf From RCNVMS.RCN.MASS.EDU!NLEONARD Sat Aug 29 21:34:04 1992 Return-Path: Received: from 134.241.10.5 by reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Sat, 29 Aug 92 21:33 PDT Received: from RCNVMS.RCN.MASS.EDU by RCNVMS.RCN.MASS.EDU (PMDF #3065 ) id <01GO68NM1TSW9I4ASE@RCNVMS.RCN.MASS.EDU>; Sun, 30 Aug 1992 00:30:29 EDT Date: 30 Aug 1992 00:30:29 -0400 (EDT) From: NLEONARD@RCNVMS.RCN.MASS.EDU Subject: EPS 16+ O.S. 1.3 Bank Loads To: eps@reed.edu Message-id: <01GO68NM1TSY9I4ASE@RCNVMS.RCN.MASS.EDU> X-VMS-To: IN%"eps@reed.edu" MIME-version: 1.0 Content-transfer-encoding: 7BIT Earlier today I posted a message indicating that the Bank Load via MIDI was not working. I have it figured out now: If you backup the HD change the interleave format then restore the MIDI Bank Loads only work for certain sequences of loads. When things go bad the machine hangs. Once I figured this out it was smooth sailing. Only having done a little experimentation with the proper set up, it seem like everything was implemented as one would expect! The backup/restore to floppies works wonderfully. I am using a HD interleaved at 2 and can restore about a meg a minute. The restore save hierarchies, macros, system globals ... everything. I defraged a 20meg HD and speed up most loads by a factor of 2-4 times! Hats off to Ensoniq. Is anyone interested in effect loads via MIDI. It seems like the last year of lobbying brought us a working sysex pec, bank loads via MIDI and backup restore. This is basic stuff that saves on lots of hours of struggling with the machine. Neil Leonard nleonard@ecn.mass.edu