sutherla@qtp.ufl.edu (scott sutherland) (09/27/89)
Pete Ashdown submitted an article concerning the use of voice mail on tha Amy, similar to that on the NEXT computer. He states that the NEXT uses 8-bit sampling at 20 kHz. Well, there was a NEXT rep here at UF during a computer EXPO and he demonstrated the voice-mail attachment to a standard UNIX electronic mail system. It was very nice, and the sampling rate was only 8 kHz. I do not know if it was 8-bit, but they simply had a small clip-on microphone plugged directly into the back of the NEXT. You enter the mail window, ask for a voice mail attachment, talk into the microphone, end the input, and viola, an icon appears on the mail message indicating a voice attachment. HOWEVER, ONLY another NEXT machine can USE this attachment. Any other UNIX machine will get only garbage. The rep did not seemed concerned when I mentioned that, as Pete noted, the size of the mail message will be increased a great deal by this. The speed of the NEXT is DISAPPOINTING!! Let me explain. They are using a 68030 chip, a 68882 math chip, a custom DSP, a fast hard disk, a huge optical disk, etc.. BUT the response time for moving windows, calling up applications, updating the screen, etc. is NO faster than our own Amiga, with a mere 68000, no math chip, and our less powerful foursome (Gary, Denise, Paula, ObeseAgnes). I expected to see sparks fly, but it only fizzled. Yes, the NEXT is a fantastic machine, but... The major things the rep emphasized were a direct result of the optical disk technology. A full dictionary, with pictures and everything; a full thesaurus, etc. They showed the multitasking of the NEXT, and I was surprised at the slow down in the output to the windows that had moving demos (like out boxes, lines, etc.). With the powerful hardware in the machine, I did not expect this. Also, I am inclined to think that the NEXT people have fallen into the trap that many machines have, for instance the SUN. I am using a 3/50 with a file server as my storage device. But the desktop publishing package I am using is HUGE!! You NEED the 4 Meg just to run it. This is a waste. We have software on the Amy that is just as powerful, and it runs on 1/2 Meg, with room to spare!! The NEXT people are the same. They have this large storage medium, and the default memory config. is, I think, 4 Meg. So they do not care if their code is compact. They have so much memory and storage that they could care less if the program is much larger and more cumbersome than need be. I also noticed that the NEXT people are deceiving many people about the unique features of their machine. The rep here was going on and on about how the NEXT is the ONLY machine that can launch a program from another program or file. He showed that by clicking on an icon of a document created in their DTP that, if the DTP was not currently running, the ICON would start it and the document could be read. WE have been doing stuff similar to this for years on the amy. If I double click on an Anim icon on a fish disk, it loads and runs ShowAnim with itself as the input file. This guy from NEXT was pleased at the crowd response. I gather that none of them had seen the Amy either. Unfortunately, the local Amiga dealer was only given a small booth, and he chose to display his HP stuff instead. TYPICAL! Don't get me wrong. The NEXT is a fantastic machine. I especially loved the little feature of nested directories. What I mean is, on the Amiga, if you click on a drawer icon, you see the icons of every program in that drawer (if it has an icon). If one of these is a drawer, you can click on it and get another pictorial listing of its contents. So you have a NESTED display of: A contains B,C,D,E, and E contains F,G,H... Well, the Next has a similar thing from its "DOS" interface. If you do a dir, you get the listing of that directory. If you click on an entry in that listing that is a directory, you will get a nested listing of that subdirectory. So you can see them simultaneously. |-----------| | Main Dir |----------| | A | Dir of B |----------| | B | D | Dir of D | | C | E | G | |-----------| F | H | |----------| I | |----------| etc... You can also click on any of the entries that are executables and run them from the listing directly. So the NEXT is a nice machine. I do not think it is a major a step in the evolution of PC's as it is being made out to be. And, as I previously stated, its performance does not live up to MY expectations, given the hardware involved. BUT I WOULD GIVE MY RIGHT ARM TO HAVE ONE OF THOSE FLOPTICAL DISKS ON MY AMY!!! ;^))) PLEASE NOTE THAT THESE ARE MY OWN OPINIONS AND OBSERVATIONS. I TAKE FULL RESPONSIBILITY FOR THEIR CONTENT, OR LACK THEREOF. :) Scott Sutherland sutherla@qtp.ufl.edu. THERE, this should move me up on the Bandwasters Hall of Fame List!! Watch out Chuck, here I come!
kim@watsup.waterloo.edu (T. Kim Nguyen) (10/02/89)
In article <688@orange6.qtp.ufl.edu> sutherla@qtp.ufl.edu (scott sutherland) writes:
The speed of the NEXT is DISAPPOINTING!! Let me explain. They
are using a 68030 chip, a 68882 math chip, a custom DSP, a fast hard
disk, a huge optical disk, etc.. BUT the response time for moving
windows, calling up applications, updating the screen, etc. is NO
faster than our own Amiga, with a mere 68000, no math chip, and our
less powerful foursome (Gary, Denise, Paula, ObeseAgnes).
I just recently attended a similar NeXT demo. I disagree with your
assessment of NeXT's speed: I was amazed at how the ENTIRE window
(with all details inside) followed the mouse so quickly (no lag). The
Amiga moves only an outline of the window.
They showed the multitasking
of the NEXT, and I was surprised at the slow down in the output to the
windows that had moving demos (like out boxes, lines, etc.). With the
powerful hardware in the machine, I did not expect this.
The demo I saw was of an aspirin molecule being rotated through
various axes. The drawing essentially looked like a bunch of spheres,
but the neat thing (pointed out, of course) was that you could "see
through" the spheres (you could see other spheres/atoms behind them)
hazily. This was supposedly a highly CPU-intensive demo, so it made
sense that the other demos went rather slowly.
So the NEXT is a nice machine. I do not think it is a major a
step in the evolution of PC's as it is being made out to be.
The NeXT is indeed a major step forward in bringing Unix to Joe User.
When did you last see a graphics/mouse-based interface for a Unix
workstation?
I think the NeXT is a brilliant concept -- its user interface is
beautifully well executed. You can build application interfaces in a
matter of minutes too -- unlike the !@#$@# OS/2 Presentation Manager
which requires ages to get anything decent going.
I also believe that NeXT's marketing schemes are equally well
designed. With their floptical disk's storage of 250MB, they will be
packaging hordes of neat and useful software with their machines. The
software currently running on the NeXT can exchange all sorts of data,
including PostScript images, voice, and text in a way never before
seen on Unix (you drag icons of voice data in and out of your email
messages, you cut and past images and drag them into other
applications, etc.) (Another neat thing about those voice icons:
when you receive email containing voice data, and you display the
message you can actually see the voice icon contained in it! If you
click on the voice icon (which can be embedded in text), you
automatically hear the voice message. Talk about cool!)
Admittedly these are not new concepts on their own, but put together
in this way they prove that NeXT has a truly innovative group of
designers (as is only to be expected from Steve Jobs!).
(BTW, I have no interest whatsoever in promoting NeXTs, except that I
think that nifty machines like it deserve to be applauded.)
--
T. Kim Nguyen kim@watsup.waterloo.{edu|cdn}
kim@watsup.uwaterloo.ca
{uunet|utzoo|utai|decvax}watmath!watsup!kim
Systems Design Engineering -- University of Waterloo, Ontario, Canadakudla@pawl.rpi.edu (Robert J. Kudla) (10/02/89)
In <KIM.89Oct2022514@watsup.waterloo.edu> kim@watsup.waterloo.edu (T. Kim Nguyen) writes:
Nguyen> The demo I saw was of an aspirin molecule being rotated through
Nguyen> various axes. The drawing essentially looked like a bunch of spheres,
Nguyen> but the neat thing (pointed out, of course) was that you could "see
Nguyen> through" the spheres (you could see other spheres/atoms behind them)
Nguyen> hazily. This was supposedly a highly CPU-intensive demo, so it made
Nguyen> sense that the other demos went rather slowly.
It shouldn't have been highly CPU-intensive. You could do the same
thing on the Amiga very easily- just do the computation beforehand....
(The way to make impressive demos is *not* to slow down the machine.)
Nguyen> When did you last see a graphics/mouse-based interface for a Unix
Nguyen> workstation?
About 12 hours ago. (Sorry, I couldn't resist... and you did ask....)
:)
--
Robert Jude Kudla <kudla@pawl.rpi.edu> <kudla@acm.rpi.edu> <fw3s@RPITSMTS>
What noisy cats are we.kim@watsup.waterloo.edu (T. Kim Nguyen) (10/03/89)
In article <1989Oct2.132314.12313@rpi.edu> kudla@pawl.rpi.edu (Robert J. Kudla) writes:
It shouldn't have been highly CPU-intensive. You could do the same
thing on the Amiga very easily- just do the computation beforehand....
(The way to make impressive demos is *not* to slow down the machine.)
That makes sense, but I think the point was to show how fast the
NeXT's DSP was when it came to number crunching (so precalculating
would have made the demo irrelevant).
Nguyen> When did you last see a graphics/mouse-based interface for a Unix
Nguyen> workstation?
About 12 hours ago. (Sorry, I couldn't resist... and you did ask....)
:)
OK, I'll bite: what machine was it?
--
T. Kim Nguyen kim@watsup.waterloo.{edu|cdn}
kim@watsup.uwaterloo.ca
{uunet|utzoo|utai|decvax}watmath!watsup!kim
Systems Design Engineering -- University of Waterloo, Ontario, Canadaportuesi@tweezers.esd.sgi.com (Michael Portuesi) (10/03/89)
In article <17939@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU (David C. Navas) writes: >Nguyen> Nguyen> When did you last see a graphics/mouse-based >Nguyen> interface for a Unix Nguyen> workstation? >Nguyen> About 12 hours ago. (Sorry, I couldn't resist... and you >Nguyen> did ask....) :) >Nguyen> OK, I'll bite: what machine was it? > >A SUN 3/50 running Xwindows. Other machines in the lab were running >NeWS and the Sun proprietary environment. Friends of mine use Apollo >workstations regularly. You were saying? Woah, hang on there. I think we're referring to two different and distinct types of 'user-interface.' When the question is asked -- 'When did you last see a [GUI] for Unix', the question should have been posed as 'When did you last see a [GUI]Bench for Unix'. That is, X-Windows IS a GUI, but it has nothng to do (or at least very little to do) with disk access. All of that garbage is still type-and- backspace...:-) 'Tis Unfortunate. It sounds to me like you're inventing your own brand of terminology. All of the interfaces I've seen for handling filesystem activity [Amiga Workbench, Macintosh Finder, NeXT Browser, MS-Windows Executive, IRIS WorkSpace (yes, we have one too)] are all applications programs that run using their native window manager/GUI. In general, the term "GUI" is reserved for window managers and software toolkits to facilitate the development and use of applications using graphical user interfaces, and not for the applications themselves. In any event, NeXT does not corner the market on graphical user interfaces or their applications software for Unix workstations, nor were they the first to develop a graphical filesystem interface for Unix. They do have a really slick-looking interface, though. --M -- __ \/ Michael Portuesi Silicon Graphics Computer Systems, Inc. portuesi@SGI.COM "The best length for television programs is either 30 seconds or 8 hours." David Byrne
jdutka@wpi.wpi.edu (John Dutka) (10/03/89)
In article <KIM.89Oct3020058@watsup.waterloo.edu> kim@watsup.waterloo.edu (T. Kim Nguyen) writes: >In article <1989Oct2.132314.12313@rpi.edu> kudla@pawl.rpi.edu (Robert J. Kudla) writes: > Nguyen> When did you last see a graphics/mouse-based interface for a Unix > Nguyen> workstation? > About 12 hours ago. (Sorry, I couldn't resist... and you did ask....) >OK, I'll bite: what machine was it? I'm writing this on a DECstation 3100, which, coincidentally, has a graphics/mouse-based interface in UNIX. -- | husc6!m2c!wpi!jdutka | "No matter how big a straw, you can't suck water up | | jdutka@wpi.wpi.edu | more than 34 feet." | | jdutka@wpi.bitnet | -A WPI PROFESSOR WHO WISHES TO REMAIN ANONYMOUS | | John Dutka _________|_____________________________________________________|
kudla@pawl.rpi.edu (Robert J. Kudla) (10/03/89)
In <KIM.89Oct3020058@watsup.waterloo.edu> kim@watsup.waterloo.edu (T. Kim Nguyen) writes:
Nguyen> Nguyen> When did you last see a graphics/mouse-based
Nguyen> interface for a Unix Nguyen> workstation?
Nguyen> About 12 hours ago. (Sorry, I couldn't resist... and you
Nguyen> did ask....) :)
Nguyen> OK, I'll bite: what machine was it?
A SUN 3/50 running Xwindows. Other machines in the lab were running
NeWS and the Sun proprietary environment. Friends of mine use Apollo
workstations regularly. You were saying?
--
Robert Jude Kudla <kudla@pawl.rpi.edu> <kudla@acm.rpi.edu> <fw3s@RPITSMTS>
What noisy cats are we.navas@cory.Berkeley.EDU (David C. Navas) (10/04/89)
In article <1989Oct3.152529.17423@rpi.edu> kudla@pawl.rpi.edu (Robert J. Kudla) writes: > >In <KIM.89Oct3020058@watsup.waterloo.edu> kim@watsup.waterloo.edu (T. Kim Nguyen) writes: > >Nguyen> Nguyen> When did you last see a graphics/mouse-based >Nguyen> interface for a Unix Nguyen> workstation? >Nguyen> About 12 hours ago. (Sorry, I couldn't resist... and you >Nguyen> did ask....) :) >Nguyen> OK, I'll bite: what machine was it? > >A SUN 3/50 running Xwindows. Other machines in the lab were running >NeWS and the Sun proprietary environment. Friends of mine use Apollo >workstations regularly. You were saying? Woah, hang on there. I think we're referring to two different and distinct types of 'user-interface.' When the question is asked -- 'When did you last see a [GUI] for Unix', the question should have been posed as 'When did you last see a [GUI]Bench for Unix'. That is, X-Windows IS a GUI, but it has nothng to do (or at least very little to do) with disk access. All of that garbage is still type-and- backspace...:-) 'Tis Unfortunate. Unless X has something that Berkeley hasn't put on the Suns... The Next interface has a painless GUI based disk-access, which is VERY handy. -David PS Of course, then again, I've never *seen* a NEXT. David Navas navas@cory.berkeley.edu
ranjit@grad1.cis.upenn.edu (Ranjit Bhatnagar) (10/04/89)
>> When did you last see a graphics/mouse-based interface for a Unix >> workstation? > About 12 hours ago. (Sorry, I couldn't resist... and you did ask....) Never mind all that! What we really need to know is - how do we make the Amiga as much fun as the NeXT? The topic under discussion: VoiceMail. It would be nice to have an IFF standard for multimedia documents: documents which can include formatted text, sound, pictures, anims, and such. Does there exist something like this already? I'm thinking along the lines of: FORM MULM LAYO - layout chunk specifies how all the following chunks fit together on the page then some ILBMs, FTXTs, ANIMs, ICONs, SMUS, etc. LAYO - layout for the next page (or unit, or whatever) ...more chunks... You were afraid I was going to post a message which didn't mention AREXX, weren't you? Never fear. Imagine a document like this: FORM MULM "voicemail message" REXX "control" /* 'self' is predefined as a reference to this FORM */ do forever event = WaitForEvent(gadget) if event.type == gadgdown && event.gadget.label == "Play VoiceMail" then PlaySample(self.mulm.smpl."VoiceMail_Contents") if event.type == byebye then break ...etc... end TEXT "text of the message" (text of mail message goes here) ICON "Play VoiceMail" (icon for PLAY goes here) SMPL "VoiceMail_Contents" (sampled voice goes here) LAYO specifies that the icon "Play VoiceMail" is located after end of text The idea is that the program that reads MULtiMedia files will display the file as specified by the LAYO chunks, and certain items, such as ICONs, will be sensitive to mouse clicks. The REXX script waits for such events, occupying no CPU time and little memory if nothing happens. A number of variables are predefined for the script, which give the script pointers to every object in the MULM package. In addition, the MULM reader provides a set of functions on these objects that the REXX script can invoke, such as PlaySample, ANIMate, and so on. Comments on this idea would be appreciated. It's VoiceMail and then some. - ranjit MAIL HEAD FROM "ranjit@grad1.cis.upenn.edu" NAME "Ranjit Bhatnagar" ORGN "University of Pennsylvania" SUBJ "Re: VoiceMail on Amiga?" ... CONT ... "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... "Such a brute that even his shadow breaks things." (Lorca)
cmcmanis%pepper@Sun.COM (Chuck McManis) (10/05/89)
Ok, so Ranjit wins the prize for hitting a very big nail squarely on the head... In article <15070@netnews.upenn.edu> (Ranjit Bhatnagar) writes: >Never mind all that! What we really need to know is - how do we make >the Amiga as much fun as the NeXT? The topic under discussion: VoiceMail. Let's not limit ourselves, its official buzzword is "MultiMedia Mail" >It would be nice to have an IFF standard for multimedia documents: >documents which can include formatted text, sound, pictures, anims, >and such. Does there exist something like this already? I'm thinking >along the lines of: > > FORM MULM BZZZZZZZZZZZZZZZZZZZZT! I'm sorry that answer is incorrect. In fact IFF has a "concept" for this already, and they are called LIST's. LIST's collect FORM's and since we don't have a true "mail program" for the Amiga yet, why not just declare that all mail is "multimedia" then you can say "Oh, MultiMedia Mail, sure I got that on the Amiga. Never saw any 'text only' mail packages." So now we have List MAIL. Of course, this part is easy. We already have ILBM, FTXT, and ANIM. A short audio sample form (not 8SVX because it isn't an instrument) would be useful, anyone care to propose one? The tough part is coming up with the user interface. That will take some thought. And "printing" a message would be a real problem. (Walk over to the printer, pick up a box of 35MM slide, a videotape, some paper, and an audio cassette. ) Now of course we could "print to disk" and anyone with a multimedia compatible terminal (read Amiga) could view their mail. We could even make 3.5" disks with address stickers on them, get your "letter" from the post office, drop it into the terminal and "poof" kinda like FAX only better. One possible user interface would be analagous to something like "MailTool" one various UNIX workstations. Except that the command bar would include things like "View Image", "View Video", "Play Audio", and maybe "Print Text" Then when you read this document, you would see a little symbol [CC] or something that said "Something is attached here." And when you selected it the appropriate button would be unghosted or enabled or what have you. Or it could be as simple as an annotation See Figure 1, where you could then select "Show Figure 1" and the mail program would figure out what it was that needed to be done and then did it. If you put a built in ISDN/V.32 modem in the "terminal" one could sell as many of them as there are phones. (Can you say 100 MILLION ?) Anyway, here again is an insurmountable opportunity that Commodore could push through and make a zillion bucks on, however my money is on Apple. Fortunately we (the Amiga user community) can probably hack something together that is nicer/faster/less expensive and have the satisfaction of showing Commodore what they missed :-(. Last comment, and this is more serious than the previous one. I am *not* down on Commodore, truely. All the things about how not a single person at Commodore HQ could give a non-hacker *one* reason why they should buy an Amiga is true, but this lack of vision is hereditary and buried deep in their genesets. They are doing a lot of good stuff and the ads that are coming out this month should be phenomenal, unfortunately they are designed as a company to do two things, make it cheaper and make it cheaper. They rely entirely on third parties for giving John Q. Public any reason whatsoever to buy their product. The negative affect of this is that they are doomed to always follow on the trailing edge of application software technology. [They keep relatively up to date with their OS technology, which is a big step in the right direction.] Great box, great people, and a lot of fun to program. Let's just hope that nowhere in the commercials it says "...and the Nintendo isn't even a computer!" --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "If I were driving a Macintosh, I'd have to stop before I could turn the wheel."
hue@netcom.UUCP (Jonathan Hue) (10/05/89)
In article <688@orange6.qtp.ufl.edu>, sutherla@qtp.ufl.edu (scott sutherland) writes: > directly into the back of the NEXT. You enter the mail window, ask > for a voice mail attachment, talk into the microphone, end the input, > and viola, an icon appears on the mail message indicating a voice > attachment. HOWEVER, ONLY another NEXT machine can USE this attachment. > Any other UNIX machine will get only garbage. The rep did not seemed , Viola? What's a big violin got to do with a NeXT. Oh, you mean"voila" Another thing you can do with the Mail app is drag any icon into the mail app's window. If you drag an ordinary file (including executables) it gets compressed and encoded into printing characters. If you drag a directory's icon into the window that entire directory tree is tar'd (or something equivalent) before the compression and encoding. But all of this is invisible to you, all you see is an icon in your mail. When the recipient of the mail receives it, they can double click on the icon, which will run it if it's an executable, have workspace open a browser showing you all the files in it if it's a directory, or call up something like Edit if it's a normal text file. Generally, you want to drag directories into mail because you can't drag the icons out of mail. The only way to save the files is to drag them out of the new browser into another browser. It's pretty handy when you want to send someone an entire directory tree thru email. Because the Speaker and Listener classes are provided in the NeXT libraries, you can write applications which understand icons being dragged into their windows. This is similar to the postings about the "Crazy AmigaDOS idea". For example, you could write an "ARC" app which would show Noah's ark, and then you would drag files into the ark, which would ARC those files. Then you could drag the resulting file into your "Kermit" app (or maybe your "tip" app) and have it automatically dial up some other system, log in, and transfer the file. Also, even though only mail app understand attachments, that doesn't mean you couldn't hack something together to decode the file and play the sound on a Sun SparcStation, it's already been done. > The speed of the NEXT is DISAPPOINTING!! Let me explain. They > are using a 68030 chip, a 68882 math chip, a custom DSP, a fast hard > disk, a huge optical disk, etc.. BUT the response time for moving > windows, calling up applications, updating the screen, etc. is NO > faster than our own Amiga, with a mere 68000, no math chip, and our > less powerful foursome (Gary, Denise, Paula, ObeseAgnes). Considering that window moves are done by executing a loop written in PostScript, I think its speed is f'ing incredibly fast . Yes, if all you want to do is blast pixels, you can go faster by scribbling on the frame buffer yourself, but IMHO, the response of the NeXT is sufficient and the benefits of Display PostScript window server definitely outweigh the speed penalty. It's not suprising that apps take a while to launch compared to the Amiga, since good Amiga SCSI drives are at least as fast as those on the NeXT, and some of their executables are big. > file server as my storage device. But the desktop publishing package > I am using is HUGE!! You NEED the 4 Meg just to run it. This is a > waste. We have software on the Amy that is just as powerful, and it > runs on 1/2 Meg, with room to spare!! The NEXT people are the same. OK, what application on the Amiga is as powerful as FrameMaker and will also run in 512K? > They have this large storage medium, and the default memory config. > is, I think, 4 Meg. So they do not care if their code is compact. > They have so much memory and storage that they could care less if the > program is much larger and more cumbersome than need be. It would be nice if they were smaller, but with 1Mx9 SIMMs under $100, it's reasonable to have a 16MB NeXT. > I also noticed that the NEXT people are deceiving many people > about the unique features of their machine. The rep here was going > on and on about how the NEXT is the ONLY machine that can launch a > program from another program or file. He showed that by clicking on > an icon of a document created in their DTP that, if the DTP was not > currently running, the ICON would start it and the document could be > read. WE have been doing stuff similar to this for years on the amy. > If I double click on an Anim icon on a fish disk, it loads and runs > ShowAnim with itself as the input file. This guy from NEXT was pleased > at the crowd response. I gather that none of them had seen the Amy > either. Unfortunately, the local Amiga dealer was only given a small > booth, and he chose to display his HP stuff instead. TYPICAL! No, you just didn't understand what he was saying. Under WB1.3, tell me how you are going to double click on a file which doesn't have an icon? With the NeXT, double clicking on a file in the browser (every file has an icon) will bring up the appropriate app for the file (i.e. Edit, Preview, WriteNow, etc). And unless I'm mistaken, on the Amiga you will wind up with two copies of an executable in memory (assuming it's not resident) if you double-click on two different icons that use the same tool. On the NeXT it just sends a message to the app (starting it if necessary) to bring up another window for that file (Edit for example). > So the NEXT is a nice machine. I do not think it is a major a > step in the evolution of PC's as it is being made out to be. And, as > I previously stated, its performance does not live up to MY > expectations, given the hardware involved. BUT I WOULD GIVE MY RIGHT > ARM TO HAVE ONE OF THOSE FLOPTICAL DISKS ON MY AMY!!! ;^))) It isn't a major step if you only compare the features it has in common with other computers. IMHO, it is a major step when you consider the features it has that no one else does, and how well they all work together. Object-oriented programmers interface to the user-interface, sound, and music kits, 44.1Khz 16-bit stereo sound, use of IPC between apps (gee, that sounds familiar), Display PostScript based window server with compositing, Mach kernel, high-capacity random access removable media, bundled with Dictionary, Mathmatica, WriteNow, on-line user manuals, etc. And, most importantly, it's the first UNIX machine I've ever seen where you can get a lot of work done without ever typing at a shell prompt. Hey, if you like the Amiga, you've got to like the NeXT too. -Jonathan
peter@sugar.hackercorp.com (Peter da Silva) (10/05/89)
In article <125829@sun.Eng.Sun.COM>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > In fact IFF has a "concept" for this already, and they are called LIST's. You mean CATs. All the FORMs in a LIST have to be the same type. You need to use a CAT for a heterogenous collection. Karl Lehenbauer's IFF CAT archiver already provides a tool for manipulating the beasts. > Of course, this part is easy. We already have ILBM, FTXT, and ANIM. A short > audio sample form (not 8SVX because it isn't an instrument) would be useful, > anyone care to propose one? 8SVX isn't an instrument. That's FORM INST. FORM 8SVX is just fine for this. > Anyway, here again is an insurmountable opportunity that Commodore could > push through and make a zillion bucks on, however my money is on Apple. Sigh. Yes. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>
new@udel.edu (Darren New) (10/05/89)
So what is this "Display PostScript" stuff? Is it anything like Sun's Network-Extensible-Window-System (basically, postscript w/ multiple windows, multitasking, and input capabilities)? -- Darren
pete@i-core.UUCP (Pete Ashdown) (10/07/89)
.edu> <125829@sun.Eng.Sun.COM> Chuckles writes: >The tough part is coming up with the user interface. No actually, I visualized that as the rather easy part. Look at the NeXT's user interface for mail. Its rather nice actually compared to what I'm using now (actually they can't be compared, its EXTREMELY NICE). It shows a cute picture of the sender that would be sent by request and stored with the mail program, a box with the persons full name, and buttons for deleting, sending, mailboxes, and finding. Its also got a small digital display and calendar pad that shows the date. Then below all of that, its got the actual message, all nicely formatted with type-styles and such. Now, IF the person has a voice mail message, there is a pair of lips where the message has been inserted into the document. The user clicks on the lips and thus the program to play the sound is run. This also works with Write Now documents, that is, if the person wants to include their resume' in full formatted form, its got a Write Now icon. Its all very slick, and its all very possible to implement on the Amiga. The idea for additional forms besides digitizations would be great. However, the voice mail format should go along with NeXT's voice mail format, so its all compatible. There could be additional icons for IFF pictures, 8SVX, ANIMs etc. Although these wouldn't work if you sent them to a NeXT recipient, they certainly _could_ in some way or another in the future. Let's use their current format, then let them play catch-up. Which brings me to the next (sic) point, is this format PD? Maybe Ali can answer that one. -- (^\__/^) pete@i-core.uucp uunet!iconsys!caeco!i-core / . . \ <=== BEWARE! The Snugglesoft Bear! \ ~ / <=== Spawn of Satan and the downfall of Western Civilization! ( )( ) Pete Ashdown - Slack Monger Extraordinare - Amiga Evangelist
karl@sugar.hackercorp.com (Karl Lehenbauer) (10/07/89)
In article <125829@sun.Eng.Sun.COM>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > A short audio sample form (not 8SVX because it isn't an instrument) would be > useful, anyone care to propose one? In article <4283@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >8SVX isn't an instrument. That's FORM INST. FORM 8SVX is just fine for this. You're both right -- and wrong. It's an instrument. It's a one-shot sample. It also makes a great breath mint. Yes, IFF 8SVX files can be simple recorded sounds that play back at a single specified rate, or they can be multioctave (one or more octaves) instruments consisting of one sample per octave. Actually, one or two samples per octave, in that there can be a one-shot header portion and/or a loop portion for the sound. A good Amiga multimedia program would have to be able to play SMUS songs, and ought to be able to play MIDI file format (MFF) type 0, 1 and 2 files, because MIDI files can have pitchwheel and modwheel bends and such, which SMUS cannot. Plus MFF is easier to record stuff in realtime and with velocity sensitivity, and lots of sequencer programs (including PC and Mac ones) can write them. I have these two pieces of the puzzle, by the way. There's an ANIM player on Fish 86 or so, and ILBM readers abound. Hmm... -- -- uunet!sugar!karl "There is hopeful symbolism in the fact that -- flags do not wave in a vacuum." -- Arthur C. Clarke -- Usenet access: (713) 438-5018
shf@well.UUCP (Stuart H. Ferguson) (10/13/89)
+-- peter@sugar.hackercorp.com (Peter da Silva) writes: | All the FORMs in a LIST have to be the same type. I'm pretty sure this is utter nonsense. A LIST can have any IFF entity in it, including CAT's and other LIST's. The thing that makes LIST's special is their lexical scoping. | Karl Lehenbauer's IFF CAT archiver already provides a tool for | manipulating the beasts. Has the problem with this been fixed? I remember noticing that the early one created incorrect IFF files. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (ferguson@metaphor.com)
karl@sugar.hackercorp.com (Karl Lehenbauer) (10/15/89)
In article <14085@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes, regarding my IFF CAT archiver: >Has the problem with this been fixed? I remember noticing that the >early one created incorrect IFF files. What Stuart is referring to is that the CAT archiver embeds a chunk containing the archive entry name (i.e. filename) within the FORMs that you save, rather than external to it. Stuart contacted me when the first version of the CAT archiver came out, saying that it was illegal to embed chunks within FORMs that your program doesn't understand. After careful reading of the spec, I believe that it *is* legal to embed chunks within FORMs you don't understand, however, the original choice of the entry name chunk ID (FNAM) was very poor and, further, I agree with Stuart that the archiver should not have done this because it would be better in many ways (including reducing overhead) to have this information outside of the FORM being archived, but of course in some IFF-compatible manner. Peter and Stuart both wanted it to use LISTs, as I recall, because they didn't like my plan of just having FORM IFAR chunks before the real chunks, i.e. the adjacent position of IFAR FORM and user's archive FORM chunks associated user's name (and eventually other info chunks) to user's FORM. Of course, I would probably have to write it and the LIST way is a lot harder, plus the advantage of the archive not having to get too heavy into cracking FORMs (as it sort of does now) is somewhat reduced, because they're wanting a more complicated structure. One thing about the archiver, if you retrieve a FORM back into a file, it is supposed to remove the archive name chunk from the FORM. So it shouldn't impact programs that only know FORMs. (Stuart reported trouble when a FORM already contained an FNAM chunk.) Anyway, I had need of it. I didn't have time to do a massive rewrite. So I fixed a bug that could cause some entry names to be shortened and renamed the name chunk to IFAR. Since there aren't any commercial CAT readers that I know of, you guys will be writing or adapting your own ILBM, 8SVX, etc FORM-reading code to read from the CAT (it's pretty easy, if you have or adopt a read routine that can start reading a file that's already open and leave the file pointer at the start of the next chunk, it can read files and FORMs -- and take anything else you need from the archiver source (it's public domain)), so your code shouldn't freak out when it sees an IFAR chunk, since you can make sure it won't. -- -- uunet!sugar!karl "There is hopeful symbolism in the fact that -- flags do not wave in a vacuum." -- Arthur C. Clarke -- Usenet access: (713) 438-5018