HDTenEightyP/NetNews huggingface dataset:
From: lad9452@ritvax.isc.rit.edu
Subject: MIDI:  Please convince me!
Reply-To: lad9452@ritvax.isc.rit.edu
Organization: Rochester Institute of Technology
Date: Sun, 22 Nov 1992 17:34:37 GMT

I would appreciate someone out there with Mac MIDI experience and perhaps
IBM pc MIDI background to compare the two systems.  Please explain to me
IF and WHY the Mac is truly a superior way to go.

Currently I own an IBM pc (386 DX compatible).  It's been great for my
programming needs for work and school.  However, I am leery of investing
in MIDI software/hardware because of incompatibility issues.

I just bought the MACWORLD Music and Sound Bible (1400 pages) because I
am interested in knowing what the Mac has to offer.  For one, at least
there's this book!

I want to buy a computer that I will dedicate for music use only.  I have
looked at the Mac Classic II as a cheap entry point, but I'm also thinking
about future expandability into hard drive recording.

Anyway, just convince me.  I'd be interested in your setups (software,
MIDI card, type of Mac).  If you feel it's more appropriate to e-mail me
this information, please do so.  Thanks!
From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re:  EGGPLANT, IMPLANT, EMPATH, BLAZEPLANT...
Date: 23 Nov 92 15:48:09 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <vmz1=g#@rpi.edu>, danaf@bray1a.its.rpi.edu (Frank R. Dana Jr.) writes:
> In article <root.02w9@rkamiga.UUCP>, root@rkamiga.UUCP (Rick Kelly) writes:
> |> 
> |> External SCSI drives for the Mac have a pc board inside that translates
> |> Apple SCSI to real SCSI.

Hmm. Oddly enough, Apple SCSI is real SCSI.

My drives have no such "board".

Indeed, you can remove drives from external disks and put them right in
your Mac as internal disks. No difference.

> The Amiga, on the other hand, uses it external to the drives. Which means you
> buy ONE controller card, and you can use SEVEN real SCSI drives...

You can do the same with the Mac. And it isn't limited to disk drives,
either, you can connect all kinds of SCSI devices.

> |> But don't blame Apple.  Adobe gets a $500-1000 license fee depending on
> |> what level of Postcript that a printer uses.
> 
> That's sick.

No it ain't. After all, the Laser Printer manufacturers are using Adobe
code in their product. That code is valuable, hence the license fee.

> |> [ ADB -- multiple keyboards ]
> Multiple keyboards? Gee, I can see where THAT might be useful... 8)

Multiple keyboards (or other input devices) are extremely useful.

Two keyboards are really handy for training. Both people can have their
hands on the keyboard at the same time.

And, you can easily have a mouse, trackball and tablet all at the same
time. And use them interchangably. Useful.

> That is, from the latest information I've heard so far, patently NOT TRUE.
> Every computer has, at the top of its line, display options which meet and 
> surpass the Toaster's capabilities (yes, including the Amiga...), but NOTHING
> out there can (yet...) do all of the VIDEO (as opposed to display...) things
> that the Toaster can do!

That's not true. There are editing packages available for both PC and Mac
that can do everything a Toaster can do and more. The only problem with 
these setups is they cost a lot more than a toaster does.

I've also heard a rumour that the Toaster on a NuBus card is coming, so soon
Mac users will have the option of buying a Toaster sans Amiga.

> The Toaster killers are coming... they will most likely be for the PC first,
> and will probably cost $4000-$10,000. That's all rumour, of course...

IMHO, the Toaster for NuBus would certainly take away a lot of the advantage
for Amiga sales in this area. It would also generate a large number of
Toaster sales. This is good for NuTek, good for Mac, bad for Amiga.

That's life.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.
From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: specifically comparing NeXT with Mac...
Date: 23 Nov 92 18:14:04 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Nov14.050343.17566@cubetech.com>, andrew@cubetech.com writes:
> In article <6311.2b023f91@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>>Again, things make sense when you consider how a product is used. The fact
>>that the NeXT doesn't have small, inexpensive colour products limits its
>>potential use.
> 
> Many things limit the NeXT's potential use, but inexpensive colour
> products aren't one of them.  

Andrew,

You missed the previous discussion of the post. Someone compared the NeXT
color capabilities with the Mac. Note that you can get a color Mac for an
extremely low price with an LC. NeXT products that support color are
significantly more expensive.

Because of this, if you have a small application that requires color, you
might choose to use an LC, but not a NeXT. The NeXT isn't suited for that
application.

It isn't a question of power or capabilities, but of price points and
marketing. NeXT isn't targeting this market, so this lack of low priced
color machines limits the potential use.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.

Xref: sparky comp.sys.mac.advocacy:2743 comp.sys.amiga.advocacy:29474
From: root@rkamiga.UUCP (Rick Kelly)
Newsgroups: comp.sys.mac.advocacy,comp.sys.amiga.advocacy
Subject: Re:  EGGPLANT, IMPLANT, EMPATH, BLAZEPLANT...
Distribution: world
Date: 18 Nov 92 14:55:09 EST
Organization: Rick's Amiga

In article <BxtwrB.ByD@news.cso.uiuc.edu> tinsel@uiuc.edu (Thomas Aaron Insel) writes:
>dtiberio@csws19.ic.sunysb.edu (David Tiberio) writes:
>
>> 	Does a Quadra have IBM slots in it? Does it use IBM compatible
>> peripherals, or do you notice how all the ports support Apple's own greedy
>> standard (they used to give free computers to schools, but you had to buy
>> the $1,000 printers and $1,000 monitors from them...what a bargain)? Does
>> it have an accelerator slot? Does it support the Video Toaster? Does it
>> output to a VCR or TV? Douse it have two, count 'em, two joystick ports?
>> Does the software cost under $500? Does the hardware cost the same as
>> IBM compatible hardware? Does it have true pre-emptive multitasking?
>
>Ports are Apple's own standard???
>
>Serial -- OK, you need a special cable.  $20 if you get ripped off, 
>  probably less.
>Monitor -- You can use nearly any VGA multisynch, again the cable is a
>  little different, but most manufacturers will put a Mac connector on
>  at no extra charge when you order.
>SCSI -- Top of the line PC systems use SCSI.

External SCSI drives for the Mac have a pc board inside that translates
Apple SCSI to real SCSI.

>Printer -- It sure as hell doesn't cost $1000 for decent Mac printer.
>  300 dpi postscript laser printers can be had for less.  OK, it can't
>  use a parallel printer without a relatively expensive adaptor box,
>  but don't try and tell me Apple invented serial printers.  I have
>  a serial printer at home that was designed before the Apple ][ was
>  sold.

A less than $1000 Apple laser printer uses TrueType rather than Postscript.

But don't blame Apple.  Adobe gets a $500-1000 license fee depending on
what level of Postcript that a printer uses.

>ADB -- OK, PC's don't let you hook up multiple keyboards.  This is
>  different.  But, non-Apple ADB keyboards can be purchased for about
>  as much as a good PC keyboard.
>OK, the floppy port's different.  You win.
>
>I'm pretty happy the Mac doesn't have ISA slots.  Why do you think that
>good PC's have EISA and/or local bus slots?  PC-standard busses slow the
>computer down.

Localbus disk controllers can also slow a PC down when it is running a
multitasking OS.

>I'm not sure about the video toaster, but it does have equivalent A-V
>tools.  They probably do cost more, you're right.
>-- 
>Thomas Insel (tinsel@uiuc.edu)
>  s-mail: 208 Saunders, 906 West College Court, Urbana IL 61801

--

--
Rick Kelly		Rick's Amiga		Framingham, Mass.

		think!unixland!rmkhome!rkamiga!root
From: steele@vlsi.caltech.edu (Craig Steele)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Performa 600
Date: 20 Nov 1992 02:15:23 GMT
Organization: California Institute of Technology
Distribution: usa
Reply-To: steele@vlsi.caltech.edu (Craig Steele)
NNTP-Posting-Host: kiwi.cs.caltech.edu

The vx has a 32 KB cache and installed floating-point chip.  I believe
that the 600 has a socket for the FPU, but the cache probably cannot
be reasonably retrofit, since I think its chips are surface-mounted
on the logic board.

Craig Steele, steele@vlsi.caltech.edu
Newsgroups: comp.sys.mac,comp.sys.mac.misc
From: koehn@vms.macc.wisc.edu
Subject: Re: formating disks
Organization:  University of Wisconsin Academic Computing Center
Date: 23 NOV 92 22:38:30    

In article <1992Nov23.193054.5821@spike.insci.com>, tom@mai.insci.com (Tom Chan) writes...

> 
>Does anybody know why when you format a disk on the SE, you can't read it on the Quadra?
>Is there a work around?
> 
>Any help will be appreciated.
> 
>Tom Chan

Tom, it sounds like you took a high-density disk, stuck it into an SE with a 
non-FDHD (non-High Density) disk drive, and formatted it as a double sided disk. 
The disk will never again function as a high density disk, but if you put a 
piece of scotch tape over the hole on the left side of the disk (the one WITHOUT 
the little slider on the back) you will be able to read it on macs with 
high-density drives.

In the future, be sure to format only low density disks (they don't have the 
extra hole) on low-density macs.

Brad Koehn
koehn@macc.wisc.edu
Xref: sparky comp.sys.mac:469 comp.sys.mac.misc:19395
From: bennett@dstos3.dsto.gov.au
Newsgroups: comp.sys.mac,comp.sys.mac.misc
Subject: Re: amiga -> mac & vice versa
Date: 20 Nov 92 11:27:58 CST
Organization: Defence Science and Technology Organisation

In article <Bx2ByF.9u9@cs.dal.ca>, powell@ug.cs.dal.ca (Joel E Powell) writes:
> universal, right?  Is there some shareware/freeware I can get to allow me
> to read and convert Amiga disks?

If you have a Mac with a superdrive you can read/write MS-DOS discs.  Put 
the MultiDOS driver on the Amiga for the same functionality.  You then have 
bidirectional file transfer.  I do it all the time :-)

Regards,

John Bennett                                   bennett@dstos3.dsto.gov.au
Head, I.T. Services Development                Phone : +61 8 259 5292
Corporate Information Systems                  FAX   : +61 8 259 5537
DEFENCE SCIENCE AND TECHNOLOGY ORGANISATION    Postal: Bld 73 Labs Area
AUSTRALIA                                              PO Box 1500 Salisbury 
                                                       South Australia  5108
                                                       AUSTRALIA
From: GILLAM.R@AppleLink.Apple.COM (Richard Gillam,GEIS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Help! Address of data mem
Date: 19 Nov 92 15:13:00 GMT
Organization: AppleLink Gateway

Nick--
 
>If the function being called is in another segment, and that segment is
>unloaded, the segment load caused by calling that function will move memory.
 
You're absolutely right.  I forgot about that case.
 
--Rich Gillam
From: werner@soe.berkeley.edu (John Werner)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: What is MacApp?
Followup-To: comp.sys.mac.oop.macapp3
Date: 17 Nov 1992 23:24:29 GMT
Organization: UC Berkeley School of Education
Distribution: world
NNTP-Posting-Host: 128.32.157.31

MacApp is an "object-oriented application framework" for creating Mac
applications.  It consists of a bunch of C++ classes (also usable from
Object Pascal) that implement objects common in Mac programs.  Some of the
classes are TApplication, TDocument, TWindow, TView, etc.  All of the
infrastructure for hooking these objects together, handling windows,
dispatching menu commands and other events, figuring out where the mouse
was clicked, supporting Undo, and so on, are built in.

To write an application, you create customized subclasses that implement
your application-specific behavior.  Usually you have to create a TDocument
subclass to store your data, a TView subclass to display it, and a bunch of
TCommand subclasses to manipulate it.  It's not really quite this simple,
of course, but once you've learned MacApp it makes writing applications a
lot easier.

--
John Werner                         werner@soe.berkeley.edu
UC Berkeley School of Education     510-642-9651
Newsgroups: comp.sys.mac.oop.macapp3
From: lasleyse@wam.umd.edu (Scott E. Lasley)
Subject: Re: Future of MacApp
Summary: MacApp bug list
Keywords: MacApp bug
Organization: University of Maryland, College Park
Date: Wed, 18 Nov 1992 15:30:00 GMT

In article <werner-171192103823@128.32.157.31> werner@soe.berkeley.edu (John Werner) writes:
>
>Most of what I've heard about this is second-hand, but I think I have it
>right.  Apple has stopped all but bug-fixing on MacApp.  I'll actually be
>surprised if we even see another bug-fix release.  Most of the former
>MacApp team is now working on "Bedrock", a new class library being jointly
>developed by Apple and Symantec (makers of Think C).  Bedrock is supposed
>to be a multi-platform, and will run on (at least) Windows.  Apple has said
>there will be some sort of migration path from MacApp to Bedrock, but I
>don't know any details.
>

I seem to recall seeing a bug list for MacApp 3 mentioned in one of the 
MacAppTech postings.  If it does exist, could it be posted here or placed
at ftp.apple.com?

Thanks.

scott e lasley   lasleyse@wam.umd.edu
Newsgroups: comp.sys.mac.oop.macapp3
From: ksand@apple.com (Kent Sandvik )
Subject: Re: Future of MacApp
Date: Thu, 19 Nov 1992 02:10:20 GMT
Organization: Apple
Followup-To: comp.sys.mac.oop.macapp3

In article <1992Nov18.153000.9281@wam.umd.edu>, lasleyse@wam.umd.edu (Scott
E. Lasley) wrote:
> I seem to recall seeing a bug list for MacApp 3 mentioned in one of the 
> MacAppTech postings.  If it does exist, could it be posted here or placed
> at ftp.apple.com?

We are actually (DTS) sanitizing this list so it will be an official
document published on ftp.apple.com, CServe and similar places. Please
don't distribute the AppleLink document because it will just stop
us from publishing the real document with future updates.

Stay tuned for more info soon.

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
From: DIGIMATCH@AppleLink.Apple.COM (3M, Ran Bedekar,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: "Bare" views in Ad Lib
Date: 19 Nov 92 13:54:00 GMT
Organization: AppleLink Gateway

Rich,
The 'View' format in MacApp 3.0 requires that a single view be at the top of a
hierarchy saved as a resource.  This was not the case in MA2.
If you try to put multiple views at the top level (without using a window as
your top view) Ad Lib will enclose them with a generic TView with the id
'base'.  (This is mentioned in the manual but not described at length.)  If you
edit this view by adding more views at the top level (i.e., even with 'base')
you will get another 'base' to enclose them all.  The only way to avoid this is
to make sure that all view resources contain only one view at the top of the
hierarchy.
 
Regards,
Nick
From: werner@soe.berkeley.edu (John Werner)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: long GridView
Followup-To: comp.sys.mac.oop.macapp3
Date: 20 Nov 1992 19:33:54 GMT
Organization: UC Berkeley School of Education
Distribution: world
NNTP-Posting-Host: 128.32.157.31

In article <1992Nov20.174230.13144@ucsu.Colorado.EDU>,
steelem@rintintin.Colorado.EDU (STEELE MARK A) wrote:
> I am working on an application that uses the a ListView. This particular
> app needs to be able to handle more then 32K items in the list.

The best answer is probably "roll your own".  If all you need is a list,
with constant row heights, this probably won't be too hard.  And it will
probably be easier in the long run than all the hacks you'll have to make
to get TGridView to work.  The only tricky part will probably be
remembering which items in the list are selected.  Perhaps you could do
this with some sort of array or linked list of (start,end) selection
ranges.

--
John Werner                         werner@soe.berkeley.edu
UC Berkeley School of Education     510-642-9651
Newsgroups: comp.sys.mac.oop.macapp3
From: steelem@rintintin.Colorado.EDU (STEELE MARK A)
Subject: long GridView
Organization: University of Colorado, Boulder
Distribution: na
Date: Fri, 20 Nov 1992 17:42:30 GMT

I am working on an application that uses the a ListView. This particular
app needs to be able to handle more then 32K items in the list. A solution
would be to change the boundries in GridView from short to long. This
approach will disable the selecting using regions. Does anybody know of
a better solution?

Mark Steele
steelem@rintintin.colorado.edu
From: ENS.CC@AppleLink.Apple.COM (ENS Computer Consulting,CAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: RE>CommToolbox Objects??
Date: 23 Nov 92 19:42:00 GMT
Organization: AppleLink Gateway

Attn: Automoble Assoc,T Phillips,|BC
Attn: MACAPP 3 TECH$
Attn: Chris Matichuk
SentBy: Paul Ens
 
RE>CommToolbox Objects??                             11/23/92   1:14 PM
 
> I'm hoping that some one there might be able to point me in the
> direction of some CommToolbox objects, or some sample code of
> CommToolbox used in MacApp.
> I'm currently writing an in-house application which will need
> to be able to open a 3270 session.  Any help you could give me
> would be appreciated.
 
John,
 
I have written a number of mainframe (3270, 5270 and VT100) front-end
applications using MacApp with a product called Blacksmith from CEL
Corporation. It is VERY comprehensive in both its depth of tools as well as
the impressive array of hardware/network configurations that it uses (SNAops,
MacIrma, Avatar, TriData, etc...).
 
Currently, their product provides interfaces to Pascal, C, Hypercard,
Supercard, 4D and Omnis 7. Right now, they are in the late beta stages of
their support for MacApp 3.0.1.
 
I would STRONGLY suggest that you contact them. I have tried a great number of
front-ending tools and can quite confidently say that this is the best on the
market. It is also extremely competitively priced.
 
If you wish to contact CEL their phone number is (403) 463-9090. Thier
Applelink address is CEL.MKTG.
 
Hope this helps,
 
Paul Ens
ENS Computer Consulting
Saskatoon, Sk CANADA
From: lenoil@Apple.COM (Robert Lenoil)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Scope of Newsgroup
Date: 17 Nov 92 05:51:08 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <1992Nov17.031903.15278@reed.edu> yeung@reed.edu (Woodrow Yeung) writes:
>Can we change this newsgroup to just comp.sys.mac.oop.macapp?  I assume
>MacApp 2.0 will be discussed here too.

The time for suggestions like this was during the Request For Discussion that
went out to comp.sys.mac.announce and other relevant newsgroups. The discussion
has ended, the voting has occurred, the group has been created, and it will
*not* include discussions of MacApp 2. This group is gatewayed to the MacApp 3
mailing list on AppleLink, and those people don't want to start receiving
inapplicable mail. If you want to talk about MacApp 2, send mail to
MacApp.Admin@AppleLink.Apple.com and ask to be placed on the MacApp2Tech$
mailing list.

Robert Lenoil
Vice President, MADA (but speaking on my own behalf)
From: werner@soe.berkeley.edu (John Werner)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Future of MacApp
Followup-To: comp.sys.mac.oop.macapp3
Date: 17 Nov 1992 18:37:24 GMT
Organization: UC Berkeley School of Education
Distribution: world
NNTP-Posting-Host: 128.32.157.31

In article <1992Nov17.172554.524@bellahs.com>, John Jamison wrote:
> I understand that Apple has publicly announced the end of
> development of MacApp. Can a kind soul please fill me
> in on the details of the announcement?  What are they
> saying to all of the early converts who now have a dead
> programming environment?

Most of what I've heard about this is second-hand, but I think I have it
right.  Apple has stopped all but bug-fixing on MacApp.  I'll actually be
surprised if we even see another bug-fix release.  Most of the former
MacApp team is now working on "Bedrock", a new class library being jointly
developed by Apple and Symantec (makers of Think C).  Bedrock is supposed
to be a multi-platform, and will run on (at least) Windows.  Apple has said
there will be some sort of migration path from MacApp to Bedrock, but I
don't know any details.

--
John Werner                         werner@soe.berkeley.edu
UC Berkeley School of Education     510-642-9651
From: JHA.RD.DVJ@AppleLink.Apple.COM (Ha Telecom, Takao Teshi,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Osaka Font
Date: 19 Nov 92 09:31:00 GMT
Organization: AppleLink Gateway

From : Howard Hendricks,Jr.
               JHA.RD.DVJ
   November 19, 1992
 
To whom it may concern:
 
 
Does anyone out there know if the following styles exist for the Osaka font-
Italic, Outline, Condensed, Extended or Underlined? If so, please send word as
soon as possible. It would also be appreciated if you could include the font ID
number for these items.
 
   Thank you.
 
 
Sincerely,
 
Howard M. Hendricks, Jr.
From: NAVARRETE@AppleLink.Apple.COM (Navarrete, Ed)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Document File Resources
Date: 23 Nov 92 19:36:00 GMT
Organization: AppleLink Gateway

Leigh,
 
It sounds like the resource fork is nopt Open.  Check your parameters to
NewFile.
 
Ed Navarrete
DTS
From: D3431@AppleLink.Apple.COM (MacroMedia Programmers,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: UFloatWindow & Kotoeri palette
Date: 19 Nov 92 01:10:00 GMT
Organization: AppleLink Gateway


 
Dear MACAPP2TECH$ and MACAPP3TECH$ folks,
 
Macromedia has several applications written with MacApp 2 which exhibit a
common bug under KanjiTalk 7.1: they crash when the Kotoeri palette is opened.
These apps all use the UFloatWindow extension to MacApp to handle their
floating windows.
 
I believe that the problem is in MABringToFront in UFloatWindow.inc1.p. This
routine is MacApp 2's patch for BringToFront that preserves window layering.
The code uses the conditional
 
                    windPeek^.windowKind < 0
 
to determine if the window is a system window. Since the Kotoeri palette has a
windowKind of 7, it is not recognized as a system window. Instead the code for
handling document windows gets executed, and when the SendBehind trap gets
called a bus error occurs.
 
When I change this conditional to
 
    (windPeek^.windowKind < userKind) & (windPeek^.windowKind <> dialogKind)
 
so that windows with windowKinds of 0, 1, 3, 4, 5, 6, and 7 - in addition to
those with negative values - are recognized as system windows, the problem
seems to go away. I decided to recognize all these values, rather than just 7,
because Inside Macintosh I-276 says that "WindowKind values 0, 1, and 3 through
7 are reserved for future use by the system."
 
Has anyone else encountered this problem? How did you fix it? Do you know if
this is the proper way to handle not only the Kotoeri palette but other future
system windows?
 
- Gordon Smith, Macromedia
  AppleLink D3431