From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-009 Date: Tue, 5 Apr 94 15:00:15 MET DST C.S.M.P. Digest Tue, 05 Apr 94 Volume 3 : Issue 9 Today's Topics: Better QuickTime play rates Debugging: when does an app start to execute? Full C++ Mac Framework wanted LISP on MAC MIDI Manager Source Example Making a font menu MoreFiles 1.1.1 - example file manager code NewGWorld - please help! Thread Manager 2.0 The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users as comp.sys.mac.programmer.src. ------------------------------------------------------- >From glalonde@vnet.ibm.com (Glen Lalonde) Subject: Better QuickTime play rates Date: 22 Mar 1994 14:24:34 GMT Organization: IBM Toronto Lab. I used a utility I wrote to see where time was being spent while playing a rather large(13MB) 60second movie. I found that about 50% of the machines time was spend in one routine, this routine was in the system heap and came from QT itself. It is 'cdec' number -16661, function 'Anon 48' The loop at 'Anon48'+BA is taking a LOT OF time. Anyone have any idea what this is doing? Also, and possibly more important, is that 20% of the machines time durring playback was spend in a ROM routine called _SIntRemove. This routine is 0x29c4 long, ouch! I read about it in IM V, but don't really see why it is being used so much. Can some kind person tell me, or point me, to why _SIntRemove is used at all durring movie playback?(I have inside mac(old version) 1-6). I assume you get: QD call->8.24 card driver call->some kind of interrupt gets generated? I have a //si with 8.24 on the nubus card. Thanks. My software inserts a VBL routine which inspects the program counter, thus letting me profile the system. Glen. +++++++++++++++++++++++++++ >From jim_reekes@quickmail.apple.com (Jim Reekes) Date: Tue, 22 Mar 1994 22:09:44 GMT Organization: Apple Computer, Inc. In article <2mmv32$6jh@tornews.torolab.ibm.com>, glalonde@vnet.ibm.com (Glen Lalonde) wrote: > > > I used a utility I wrote to see where time was being > spent while playing a rather large(13MB) 60second movie. > I found that about 50% of the machines time was spend in > one routine, this routine was in the system heap and > came from QT itself. It is 'cdec' number -16661, > function 'Anon 48' The loop at 'Anon48'+BA is taking > a LOT OF time. Anyone have any idea what this is doing? That's the image decompresser that draws the compressed video images to the screen. > Also, and possibly more important, is that 20% of the > machines time durring playback was spend in a ROM routine > called _SIntRemove. This routine is 0x29c4 long, ouch! > I read about it in IM V, but don't really see why it is > being used so much. Can some kind person tell me, or point > me, to why _SIntRemove is used at all durring movie > playback?(I have inside mac(old version) 1-6). It's not really _SIntRemove. You have to know the exact address and the look them up in the ROM maps. The bugger you are using is only reporting the nearest trap in front of the address in ROM you are looking at. At that location there are some VIA interrupt handlers, and below them are the SCSI transfer routines. > I assume you get: > QD call->8.24 card driver call->some kind of interrupt > gets generated? > I have a //si with 8.24 on the nubus card. Thanks. > My software inserts a VBL routine which inspects the > program counter, thus letting me profile the system. Then you should be using the ROM maps to get more accurate readings of the ROM addresses. - --------------------------------------------------------------------- Jim Reekes, Polterzeitgeist | Macintosh Toolbox Engineering | Sound Manager Expert Apple Computer, Inc. | "All opinions expressed are mine, and do 20525 Mariani Ave. MS 302-3KS | not necessarily represent those of my Cupertino, CA 95014 | employer, Apple Computer Inc." +++++++++++++++++++++++++++ >From ivanski@world.std.com (Ivan M CaveroBelaunde) Date: Tue, 22 Mar 1994 23:00:57 GMT Organization: The World Public Access UNIX, Brookline, MA glalonde@vnet.ibm.com (Glen Lalonde) writes: >I used a utility I wrote to see where time was being >spent while playing a rather large(13MB) 60second movie. >I found that about 50% of the machines time was spend in >one routine, this routine was in the system heap and >came from QT itself. It is 'cdec' number -16661, >function 'Anon 48' The loop at 'Anon48'+BA is taking >a LOT OF time. Anyone have any idea what this is doing? The 'thng' resources specify that 'cdec' -16661 is the Cinepak decompressor. What it is doing is left as an exercise for the reader ;) >Also, and possibly more important, is that 20% of the >machines time durring playback was spend in a ROM routine >called _SIntRemove. This routine is 0x29c4 long, ouch! I'm not sure it's really in _SIntRemove. The symbol lists for the ROMs are nowhere near complete, and registering execution at _SIntRemove+$XXXX doesn't necessarily mean it's stuck removing a slot interrupt. For example, the *entire* memory manager is labeled as _StripAddress+$XXXX. I could see it servicing a slot VBL call. Depending on the machine you're using, I guess it could be processing async disk I/O. Hope this helps, -Ivan - - Ivan Cavero Belaunde (ivanski@world.std.com) Avid VideoShop Project Lead Avid Technology, Inc. +++++++++++++++++++++++++++ >From rang@winternet.mpls.mn.us (Anton Rang) Date: 23 Mar 1994 00:32:46 GMT Organization: Minnesota Angsters In article <2mmv32$6jh@tornews.torolab.ibm.com> glalonde@vnet.ibm.com (Glen Lalonde) writes: >I found that about 50% of the machines time was spend in >one routine, this routine was in the system heap and >came from QT itself. It is 'cdec' number -16661, >function 'Anon 48' The loop at 'Anon48'+BA is taking >a LOT OF time. Anyone have any idea what this is doing? The 'cdec' resource is a compressor/decompressor. Presumably the loop you're looking at is handling picture decompression. >Also, and possibly more important, is that 20% of the >machines time durring playback was spend in a ROM routine >called _SIntRemove. This routine is 0x29c4 long, ouch! Actually, no, that's not the routine. It just looks like it because it is followed by a huge amount of undocumented ROM code (well, not undocumented exactly, just internal routines, not external traps.) I'd have to look at the IIsi ROM map to be sure, but that's probably either Sound Manager or QuickDraw code that you're seeing. -- Anton Rang (rang@winternet.mpls.mn.us) --------------------------- >From sgl1@kimbark.uchicago.edu (Steven Lane) Subject: Debugging: when does an app start to execute? Date: Mon, 21 Mar 1994 00:20:31 GMT Organization: University of Chicago I figure there must be an easy answer to this, but I've had no luck figuring it out. I want to set a breakpoint condition in MacsBug such that I'll drop into the debugger sometime after _Launch, as soon as the app's main code segment is entered. I've tried various things, such as waiting until CurApName or TheZone changes, but these are shots in the dark, given that I don't know how or in what order _Launch does its business, and I don't enjoy ROM exploration in large doses. So: are there any decent rules of thumb on what conditions will true at the point an app executes the first line of its own code? Any pointers would be a big help. I'll be glad to summarize if there's enough response or interest. -- - -- Steve Lane University of Chicago, Department of History sgl1@midway.uchicago.edu +++++++++++++++++++++++++++ >From wysocki@netcom.com (Chris Wysocki) Date: Mon, 21 Mar 1994 04:08:06 GMT Organization: Global Village Communication, Mountain View, CA In article <1994Mar21.002031.16537@midway.uchicago.edu> sgl1@midway.uchicago.edu writes: >I figure there must be an easy answer to this, but I've had no luck >figuring it out. I want to set a breakpoint condition in MacsBug such >that I'll drop into the debugger sometime after _Launch, as soon as >the app's main code segment is entered. For 68k applications, the easiest thing to do is set the low-memory global LoadTrap (a byte at $12D) to non-zero before launching the application. This will cause _LoadSeg to drop you into Macsbug right before RTS-ing to your code segment. I haven't figured out how to do the same thing for native applications, although I haven't had the need to do this just yet.... Chris. +++++++++++++++++++++++++++ >From zellers@berksys.com (Steve Zellers) Date: 21 Mar 1994 05:01:08 GMT Organization: Berkeley Systems, Inc. In article , wysocki@netcom.com (Chris Wysocki) wrote: > In article <1994Mar21.002031.16537@midway.uchicago.edu> sgl1@midway.uchicago.edu writes: > For 68k applications, the easiest thing to do is set the low-memory > global LoadTrap (a byte at $12D) to non-zero before launching the > application. This will cause _LoadSeg to drop you into Macsbug right > before RTS-ing to your code segment. I haven't figured out how to do > the same thing for native applications, although I haven't had the > need to do this just yet.... Holding down the control key when you launch your all will stop you in __start, assuming you're using r2db & the debugger nub. Not sure about using the nub that comes with metrowerks, however. (But if its implementing the nub interface, it might just work. --smz  -- Sr. Software Engineer Berkeley Systems, Inc. --------------------------- >From krodye@sra.com (Eric Krody) Subject: Full C++ Mac Framework wanted Date: 21 Mar 1994 15:14:49 GMT Organization: Systems Research and Applications Corp., Fairfax VA What does one do if one wants to write an application making full use of C++? Apparently, neither MacApp nor Symantec's Think Class Library take full advantage of C++ (and TCL seems to be pretty far from doing so given its heritage). I read that QuickApp offers a framework written in C++ but I don't know much about this Emergent Behavior product (nor do I know anything about Emergent Behavior). Any comments on what direction to take? Anyone used QuickApp? Anyone know Emergent Behavior's phone number or have any other useful information? +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Mon, 21 Mar 1994 10:34:31 -0800 Organization: Internet for the Olympic Peninsula In article <2mkdl9$edd@snoopy.sra.com>, krodye@sra.com (Eric Krody) wrote: > > What does one do if one wants to write an application making full use > of C++? Apparently, neither MacApp nor Symantec's Think Class Library > take full advantage of C++ (and TCL seems to be pretty far from doing > so given its heritage). I read that QuickApp offers a framework written > in C++ but I don't know much about this Emergent Behavior product (nor > do I know anything about Emergent Behavior). Any comments on what > direction to take? Anyone used QuickApp? Anyone know Emergent Behavior's > phone number or have any other useful information? > QuickApp is, er, quick. [It was also recently incorporated into a new Apple Developer University course which replaces two old object oriented courses. And it was incorporated into a course on OO for Taligent.] A new QuickApp is coming "soon", which will be compilable using Metrowerks CodeWarrior (including for Power Macintosh), and will support Apple events. Emergent Behavior is, among others, Dave Wilson (who has taught at Apple Dev U for a LONG time, and is darn good), and Steve Wilson. emergent@aol.com CodeWarrior from Metrowerks includes the "PowerPlant" framework, which looks promising. CodeWarrior is currently out in its first developer pre-release: #2 is about to emerge. 68K only, PPC only, or both. Delivered on CD. I've already switched from Symantec (I wouldn't have for an early deadline program, although some Power Macintosh code compiled by CodeWarrior is already in service (Fetch 2.1.2, as one example). I like the feel of the PowerPlant framework (by Gregory Dow of TCL fame). It's "TCL done right given modern tools and a second chance" (my quote). -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] jwbaxter@pt.olympus.net --------------------------- >From gt7572c@prism.gatech.EDU (Jason Strayer) Subject: LISP on MAC Date: 19 Mar 94 00:32:19 GMT Organization: Georgia Institute of Technology Anyone know of a good LISP compiler on Macintosh? More importantly: a LISP compiler that is going to be released for the PowerMACs? Does such a thing exist? thanks in advance, jason +++++++++++++++++++++++++++ >From Steve Bryan Date: Sun, 20 Mar 1994 07:31:08 GMT Organization: Sexton Software In article <146371@hydra.gatech.EDU> Jason Strayer, gt7572c@prism.gatech.EDU writes: >Anyone know of a good LISP compiler on Macintosh? >More importantly: a LISP compiler that is going to be released for the >PowerMACs? There's good news and bad news to report. A few years ago someone at Apple liked a product called Coral Lisp so much that they bought the company (product, developers, everything) and renamed it Macintosh Common Lisp. This has been available for a few years as a $500 product from APDA. It appears to have been rather actively supported by Apple as new features have been added to system software with regular updates on the developers' CDs. The bad news (if the $500 price tag wasn't already) is that Apple appears to have narrowed its focus entirely to C++. The most recent CD with issue 17 of develop has removed all updates to platforms other than C++. I also read somewhere else on Usenet that Apple doesn't have any plans currently to port MCL to the PowerPC. If you don't mind entertaining rumors there is a Lisp like language called Dylan that appears to have the strong support of Larry Tesler at Apple that may be coming out yet. The most interesting rumor I read about it is that Michael Kahl (developer of Lightspeed C, later called Think C, recently called many other names) is working on the project. Steve Bryan InterNet: sbryan@maroon.tc.umn.edu Sexton Software CompuServe: 76545,527 Minneapolis, MN Fax: (612) 929-1799 +++++++++++++++++++++++++++ >From brickle@ccr-p.ida.org (Frank Brickle) Date: 20 Mar 1994 08:50:51 -0500 Organization: IDA - Center for Communications Research >From article , by Steve Bryan : > In article <146371@hydra.gatech.EDU> Jason Strayer, > gt7572c@prism.gatech.EDU writes: >>Anyone know of a good LISP compiler on Macintosh? >>More importantly: a LISP compiler that is going to be released for the >>PowerMACs? > > ...I also read somewhere else on Usenet that Apple doesn't > have any plans currently to port MCL to the PowerPC. > Not exactly. What you probably read were furious postings *concluding* (in spite of all public statements on the subject from people at Apple) that MCL wouldn't be produced in a PPC-native version. +++++++++++++++++++++++++++ >From Steven Ritter Date: Sun, 20 Mar 1994 14:35:45 -0500 Organization: Psychology, Carnegie Mellon, Pittsburgh, PA Excerpts from netnews.comp.sys.mac.programmer: 20-Mar-94 Re: LISP on MAC by Frank Brickle@ccr-p.ida. > From article , by Steve Bryan .edu>: > > In article <146371@hydra.gatech.EDU> Jason Strayer, > > gt7572c@prism.gatech.EDU writes: > >>Anyone know of a good LISP compiler on Macintosh? > >>More importantly: a LISP compiler that is going to be released for the > >>PowerMACs? > > > > ...I also read somewhere else on Usenet that Apple doesn't > > have any plans currently to port MCL to the PowerPC. > > > > Not exactly. What you probably read were furious postings *concluding* > (in spite of all public statements on the subject from people at > Apple) that MCL wouldn't be produced in a PPC-native version. No, what he read was that Apple will not be producing a PPC-native version of MCL. Apple is hoping to convince someone else to do the work for them. This is basically what Rick Fleischman, the MCL product manager, posted to comp.lang.lisp.mcl. The general feeling is that the potential market for LISP is so small that no third part could make a profit from MCL, and the fact that the PowerPC is now out and Apple still hasn't found anyone to commit to doing the port doesn't inspire much confidence that it'll get done at all. A surprisingly large percentage of AI researchers use Macintoshes entirely because of MCL. These are not people who have any loyalty to the hardware and if MCL doesn't keep up, they'll leave. Steve +++++++++++++++++++++++++++ >From howard@netcom.com (Howard Berkey) Date: Sun, 20 Mar 1994 21:51:09 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) In article <4hX_KFG00iV7A2rKhE@andrew.cmu.edu> Steven Ritter writes: >Excerpts from netnews.comp.sys.mac.programmer: 20-Mar-94 Re: LISP on MAC >by Frank Brickle@ccr-p.ida. >> From article , by Steve Bryan >> .edu>: >> > In article <146371@hydra.gatech.EDU> Jason Strayer, >> > gt7572c@prism.gatech.EDU writes: >> >>Anyone know of a good LISP compiler on Macintosh? >> >>More importantly: a LISP compiler that is going to be released for the >> >>PowerMACs? >> > >> > ...I also read somewhere else on Usenet that Apple doesn't >> > have any plans currently to port MCL to the PowerPC. >> > >> >> Not exactly. What you probably read were furious postings *concluding* >> (in spite of all public statements on the subject from people at >> Apple) that MCL wouldn't be produced in a PPC-native version. > >No, what he read was that Apple will not be producing a PPC-native >version of MCL. Apple is hoping to convince someone else to do the work >for them. This is basically what Rick Fleischman, the MCL product >manager, posted to comp.lang.lisp.mcl. > >The general feeling is that the potential market for LISP is so small >that no third part could make a profit from MCL, and the fact that the >PowerPC is now out and Apple still hasn't found anyone to commit to >doing the port doesn't inspire much confidence that it'll get done at >all. >[...] That will be a true bummer, then. I know people who swear by MCL, including one who feels it is the definative PC LISP implementation. Plus it has (based on my limited experimentation) a very nice editor, considering how long it's been around. If I had need of a LISP environment, there would be no question of the one I would buy. From an aesthetic standpoint, this is nearly as bad as Symantec not continuing THINK Pascal. (Though I'm sure others will disagree :-) -H- -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Howard Berkey howard@netcom.com Kill the Wabbit! +++++++++++++++++++++++++++ >From brickle@ccr-p.ida.org (Frank Brickle) Date: 20 Mar 1994 18:24:37 -0500 Organization: IDA - Center for Communications Research >From article <4hX_KFG00iV7A2rKhE@andrew.cmu.edu>, by Steven Ritter : > > No, what he read was that Apple will not be producing a PPC-native > version of MCL. Apple is hoping to convince someone else to do the work > for them. This is basically what Rick Fleischman, the MCL product > manager, posted to comp.lang.lisp.mcl. > I believe this is a pessimistic over-reading of Rick Fleischman's postings. +++++++++++++++++++++++++++ >From Malcolm Pradhan Date: 21 Mar 1994 18:56:56 GMT Organization: Section on Medical Informatics, Stanford University In article <2milvl$9a2@snook.ccr-p.ida.org> Frank Brickle, brickle@ccr-p.ida.org writes: > From article <4hX_KFG00iV7A2rKhE@andrew.cmu.edu>, by Steven Ritter > : > > No, what he read was that Apple will not be producing a PPC-native > > version of MCL. Apple is hoping to convince someone else to do the work > > for them. This is basically what Rick Fleischman, the MCL product > > manager, posted to comp.lang.lisp.mcl. > > I believe this is a pessimistic over-reading of Rick Fleischman's > postings. Not really. Fleischman said that further development on MCL would not happen, implying that no new features would be added to the CommonLisp, CLOS or interface framework. What he did say was that bug fixes would continue, and they were looking for a 3rd party to help them port the compiler to PowerPC. The reason for the pessimistic tone is that Apple have been planning PowerPC for years, but they have only just started to look at porting MCL. It's good that they are trying to port at all it but the main reason for doing so is that some of their internal projects (and one in particular) use MCL as their compiler. My own hypothesis about the late decision to port MCL is that it was deemed easier to find a 3rd party to help with the port than it was to move the ATG project to Dylan. While MCL shouldn't be Apple's highest priority, I think their attitude is symptomatic of their general disregard for Macintosh development, as discussed by John Nagle in another thread. I like MCL a lot, and if you have a Mac and need a lisp I would recommend it. But if you are looking for a lisp system with a future then I could not recommend Mac Common Lisp, despite it being a great lisp. Interestingly enough, our lab would have purchased a number of 8100's for Lisp development, and I would have upgraded my Mac straight away if MCL were available. I'm sure Apple would have sold quite a few high-end PowerPCs on the basis of the killer combination of the 601 + MCL. Regards, Malcolm --------------------------- >From etxlepi@garbo.ericsson.se (Matti Lepist|) Subject: MIDI Manager Source Example Date: Mon, 21 Mar 1994 09:35:15 GMT Organization: Ericsson Telecom Hello! :^) Does anyone have a code example of how to use the MIDI manager lib functions for mac. I have tried to figure out how to do it by looking att the include file MIDI.h and got som things working. But when I tried to write a readHook and set it to a input port it crashes the MIDI manager when I connect some output to it that generates MIDI events... /Matti _________________________________________________________________________ Matti Lepisto: Phone: +46 8 719 5160 Design Support Fax: +46 8 719 8531 TN/ETX/TX/DV MiniCall: +46 74 44 2403 Ericsson Telecom AB E-Mail: etxlepi@garbo.ericsson.se 126 25 Stockholm, SWEDEN Memo: ERI.ETX.ETXLEPI _________________________________________________________________________ +++++++++++++++++++++++++++ >From Paul Ferguson Date: 21 Mar 1994 16:40:08 GMT Organization: Kaleida Labs, Inc. In article <1994Mar21.093515.25570@ericsson.se> Matti Lepist|, etxlepi@garbo.ericsson.se writes: > Does anyone have a code example of how to use the MIDI manager > lib functions for mac. >... > But when I tried to write a readHook and set it to a input > port it crashes the MIDI manager when I connect some output > to it that generates MIDI events... Take a look at CMIDI, my MIDI Manager class library for THINK's TCL. It includes a complete example program, Lefty, that you can examine. It's available by ftp from daemon.ncsa.uiuc.edu. As for your readHook crashing, here are two possible causes: not declaring the readHook as a pascal function (if you are programming in C), or violating restrictions on interrupt handlers if your input port is set to process packets during interrupt time. Also, if you are using THINK C, the MIDI.h file shipped with it is WAY out of date, and is incompatible with CMIDI. If you continue to have difficulties, I suggest getting the MIDI Manager programmers kit from Apple ($35US). It contains the latest headers, detailed documentation, and several example applications with full source code. --fergy - ------------------------------------------------------------------ Paul Ferguson | "It's a sick world, I'm a happy guy..." pferguson@kaleida.com | - ------------------------------------------------------------------ +++++++++++++++++++++++++++ >From mwalker@netcom.com (Mel Walker) Date: Mon, 21 Mar 1994 18:44:01 GMT Organization: Committee to Elect Dan Quayle Lord of the Cosmos Paul Ferguson (pferguson@aol.com) wrote: : If you continue to have difficulties, I suggest getting the MIDI : Manager programmers kit from Apple ($35US). It contains the latest : headers, detailed documentation, and several example applications : with full source code. Is buying the kit the only way to get the MIDI manager? Is it the cheapest way? -- Mel Walker mwalker@netcom.com "Natural exuberance is one of those qualities that makes us tigers so darn endearing!" -- Hobbes +++++++++++++++++++++++++++ >From howard@netcom.com (Howard Berkey) Date: Mon, 21 Mar 1994 18:58:42 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) In article mwalker@netcom.com (Mel Walker) writes: >Paul Ferguson (pferguson@aol.com) wrote: >: If you continue to have difficulties, I suggest getting the MIDI >: Manager programmers kit from Apple ($35US). It contains the latest >: headers, detailed documentation, and several example applications >: with full source code. > >Is buying the kit the only way to get the MIDI manager? Is it the >cheapest way? > I imagine you can get the Mgr. itself free with various software (I think Master Tracks Pro 5 came with it), but then you don't get any docs. Does APDA sell anything CHEAPER than $35? I seem to remember some t-shirts and pens in the back of the catalog :-) Seriously, the Midi Mgr. is one of the least-overpriced offerings from APDA. You get a pretty bad (IMHO) reference manual, some OK example hacks, the MIDI mgr, and Patchbay (neat idea). I haven't looked at in in a year or so but I remember being more or less immediately able to write a MIDI-driven graphics applet which would display variously sized and located rectangles based on incoming MIDI information, so it was at least SOME help :-) -H- -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Howard Berkey howard@netcom.com Kill the Wabbit! +++++++++++++++++++++++++++ >From Paul Ferguson Date: 21 Mar 1994 19:34:44 GMT Organization: Kaleida Labs, Inc. In article Mel Walker, mwalker@netcom.com writes: > Is buying the kit the only way to get the MIDI manager? Is it the > cheapest way? For whatever reason, Apple has never freely distributed the MIDI Manager as they do other System software extensions. Some MIDI software manufacturers bundle the MIDI Manager driver and PatchBay software. For programming, the MIDI Manager developer kit includes the drivers, PatchBay, programmer's documentation, source code examples, etc. BTW, the MIDI Manager will probably disappear soon, with its functionality rolled into QuickTime 2.0. Apple never really supported the MIDI Manager very well; I hope that MIDI will get more "respect" as part of QT. --fergy - ------------------------------------------------------------------ Paul Ferguson | "It's a sick world, I'm a happy guy..." pferguson@kaleida.com | - ------------------------------------------------------------------ --------------------------- >From blume@twg.com (David Blume) Subject: Making a font menu Date: Sat, 19 Mar 1994 02:26:04 GMT Organization: Gokuraku Videos - Wollongong Dept. How do you determine which fonts are available in the system software to add them to a menu? (Ie., how do you get a valid list of font names or font numbers for use with GetFontName() or GetFNum()?) Thanks, --David +---------------------------------------------------------------+ | David Blume | "I get tired thinking of all the things I | | blume@twg.com | don't want to do." --Bukowski, _Barfly_ | +---------------------------------------------------------------+ +++++++++++++++++++++++++++ >From markhanrek@aol.com (MarkHanrek) Date: 19 Mar 1994 06:17:02 -0500 Organization: America Online, Inc. (1-800-827-6364) I don't remember where I saw the example source code. Probably on the Developer CD. But look through the technotes, because I remember reading that we need to be careful how we do this, because if we do it the obvious way, :), then we will end up loading all the fonts we have into the system heap and the size of the system partition will mushroom like you wouldn't believe. The appropriate method was given for doing this, so the technotes may be a place to look next. Also, I may have seen something in d e v e l o p. Hope this helps. Mark Hanrek +++++++++++++++++++++++++++ >From petm@soda.berkeley.edu (Peter Mattis) Date: 20 Mar 1994 22:02:47 GMT Organization: Computer Science Undergrad Assoc., UCBerkeley The way I remember doing this was a simple call like this: AddResMenu(myMenu, 'FONT'); (I think 'FONT' is right, but don't quote me on it). This should append all the fonts available in the system to myMenu. Then when a user selects a font you can find its fontID based on its location in the menu (since the fonts will be in alphabetical order in the menu). If this isn't enough, e-mail me and I'll send some C source I have for making a font menu and selecting a font from it. -Peter Mattis +++++++++++++++++++++++++++ >From Doug Eernisse Date: 21 Mar 1994 02:42:13 GMT Organization: University of Michigan - College of Literature, Science, and TheArts In article <2mih67$qjo@agate.berkeley.edu> Peter Mattis, petm@soda.berkeley.edu writes: >AddResMenu(myMenu, 'FONT'); > >(I think 'FONT' is right, but don't quote me on it). > >This should append all the fonts available in the system to myMenu. >Then when a user selects a font you can find its fontID based on its >location in the menu (since the fonts will be in alphabetical order in >the menu). Does anyone have advice on a fairly direct way to only list fonts that are nonproportional fonts? This is for a special purpose application where the columns have to line up, so a proportional font doesn't work properly. Doug +++++++++++++++++++++++++++ >From kenlong@netcom.com (Ken Long) Date: Mon, 21 Mar 1994 17:23:49 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) On ftp ftp.cso.uiuc.edu, there ar 24 C "disks" (files) and one of them has the source for an Ascii program. There are actually two ascii sources on that ftp - one is for a DA, which I've updated, and added an application version and posted on a.s.m. It merely has the "charts" in the source, all laid out in a table, and "DrawStrings" them to the window. But the OTHER one in a regular ascii chart application, and it gets the characters from the keymap and puts them in a grid - just like the modern ascii chart programs (DA's) do (not as well done, thought). It's got one font menu, and a size menu. You select a font in the font menu and that fontName is now the title of the size menu. This old source does NOT compile and run as-is. I've got my copy to do so and will post it as soon as it runs *right*, but in the mean time you could get that source and look at those menu routines and it may help, in addition to the fine advice earlier in this thread. Connect to the ftp, then it's "cd mac/MUG", then "get C2.cpt.Hqx". The file is in the SuMac folder. -Ken- +++++++++++++++++++++++++++ >From kenlong@netcom.com (Ken Long) Date: Mon, 21 Mar 1994 17:26:00 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) By the way, there's another old source i've updated to run on Think C called "Font Show" which is on a.s.m, and their ftp, which may help. -Ken- +++++++++++++++++++++++++++ >From Reid Ellis Date: Tue, 22 Mar 1994 22:08:31 GMT Organization: Alias Research, Inc., Toronto ON Canada Peter Mattis writes: |AddResMenu(myMenu, 'FONT'); | |This should append all the fonts available in the system to myMenu. |Then when a user selects a font you can find its fontID based on its |location in the menu (since the fonts will be in alphabetical order in |the menu). Well, close. You find its font id by calling GetFNum() on the string in the menu item selected by the user, not by its position in the menu. If you want a subset, like proportional fonts or PostScript fonts, you have to walk the menu, deleting any items that don't match your requirements. Reid P.S. How about AddResMenu(menu, 'FOND')? -- - - Reid Ellis, Alias Research Inc. +1 416 362 9181 --------------------------- >From blob@apple.com (Brian Bechtel) Subject: MoreFiles 1.1.1 - example file manager code Date: 22 Mar 1994 07:37:32 -0800 Organization: Apple Computer, Inc., Cupertino, California MoreFiles 1.1.1 is available for anonymous ftp from the site ftp.apple.com (130.43.2.3) in the path: /dts/mac/sc/morefiles1.1.1.hqx I take it this would be a URL of ftp://ftp.apple.com/dts/mac/sc/morefiles1.1.1.hqx MoreFiles, by Jim Luther of DTS, is sample code showing how to do most of the things people ask about doing with the Macintosh file manager. In my opinion, it's very well written and valuable code. --Brian Bechtel blob@apple.com "My opinion, not Apple's" --------------------------- >From vcan@cs.uml.edu (Volkan Can) Subject: NewGWorld - please help! Date: 20 Mar 1994 15:10:25 GMT Organization: UMass-Lowell Computer Science Hello, I'm trying to make a program I'm writing, draw to an offscreen gworld.. for the life of me, I can't figure out what I am doing wrong.. when I use copybits to copy the data from the from the offscreen gworld to my window, I get garbage in my window... I drew a line offscreen and it was there but I also got a lot of other garbage. (After te copybits that is) Is some other application writing to this offscreen memory? Can someone explain to me when and where I should use the keeplocal and/or no new device or even the purge? flag with NewGWorld? please help.. also, I am setting the size of the gworld to the size of my window and the orig and dest rect's in copy bits are the same (same size as window) please leave email to me.. vc +++++++++++++++++++++++++++ >From alex@metcalf.demon.co.uk (Alex Metcalf) Date: Sun, 20 Mar 1994 17:06:09 GMT Organization: Demon Internet In article <2mhp11$626@ulowell.uml.edu>, vcan@cs.uml.edu (Volkan Can) wrote: > Hello, I'm trying to make a program I'm writing, draw to an offscreen gworld.. > for the life of me, I can't figure out what I am doing wrong.. > > when I use copybits to copy the data from the from the offscreen gworld to my > window, I get garbage in my window... Usually the problem is that people don't send dereference the GWorld correctly. Here's an example of the sort of call you want to use: CopyBits ((BitMap *) *myGWorld, (BitMap *) &gGameWindow->portPixMap, &myRect, &myRect, srcCopy, nil); Notice the dereference of the world, and sending the pointer of the window's pixmap. > Can someone explain to me when and where I should use the keeplocal and/or no > new device or even the purge? flag with NewGWorld? Don't bother using the keeplocal thing, and setting it to purge just causes extra work for you. The "no new device" option removes the problems with matching colour tables. Best thing to do is read Inside Mac 6: it's called something like the "Graphics Devices" chapter. At least, it's the one before the Sound Chapter. Hope this helps, Alex +++++++++++++++++++++++++++ >From scottsquir@aol.com (ScottSquir) Date: 21 Mar 1994 01:42:04 -0500 Organization: America Online, Inc. (1-800-827-6364) (Volkan Can) writes: >when I use copybits to copy the data from the from the offscreen gworld to >my window, I get garbage in my window... >I drew a line offscreen and it was there but I also got a lot of other >garbage. >(After te copybits that is) >Is some other application writing to this offscreen memory? Make sure you erase your GWorld first. Just use EraseRect(&theRect) before actually drawing to the GWorld. The GWorld is just memory and NewGWorld doesn't do anything except allocate it and setup the structures. -scott +++++++++++++++++++++++++++ >From markhanrek@aol.com (MarkHanrek) Date: 21 Mar 1994 12:36:03 -0500 Organization: America Online, Inc. (1-800-827-6364) Because todays information management is still primitive, we are lead to believe that all we need to do is use the NewGWorld call and we're ready to go. I did. But here is the basic NewGWorld routine I have come to use, which does all the required things that we learn about as we go along. Hopefully this will save you and others from a lot of wasted time. Hope this helps. Mark Hanrek - ---------------------------------------------------------------- Notes: The statements marked with //** are the important ones that we find out the hard way are the additional things we must do before we consider a GWorld fully prepared. The "tryTempMem" parameter allows you to easily specify if its okay for the routine to try to allocate the GWorld in MultiFinder temporary memory. This is handy, for example, when allocating an intermediate GWorld for dithering from 32-bit to 8-bit color, which is only needed momentarily and will be gone before the user gets back control. Once allocated, work with it and dispose of it normally. You could change the behavior of this parameter to force using temporary memory in the first place, and backing off to application memory, an improvement I just realized would be nice as I sit here typing this. :) When you read in pictures destined for a GWorld, get the picture's colors first, and then feed the color table to this routine when creating its GWorld, then draw the picture into the GWorld. Feel free to redesign the parameters and convenience features of this routine to suit your taste. The important thing is that our GWorlds must be clipped, erased, and have their coloring set straight before we continue on our way. //**************************************************************** OSErr CreateNewGWorld( Rect *theRect, short theDepth, CTabHandle theColors, GWorldPtr *theGWorld, Boolean tryTempMem ) { CGrafPtr previousGW; GDHandle previousGD; QDErr err; GWorldFlags theFlags; RGBColor rgbOpColor = { 0x8000, 0x8000, 0x8000 }; RGBColor rgbBlack = { 0x0000, 0x0000, 0x0000 }; RGBColor rgbWhite = { 0xFFFF, 0xFFFF, 0xFFFF }; GetGWorld( &previousGW, &previousGD ); if (( err = NewGWorld( theGWorld, theDepth, theRect, theColors, nil, 0L )) != noErr) if ( tryTempMem == true ) { if (( err = NewGWorld( theGWorld, theDepth, theRect, theColors, nil, useTempMem)) != noErr) return( err ); } else return( err ); SetGWorld( *theGWorld, nil ); ClipRect( &(**theGWorld).portRect ); //** if ( LockPixels( GetGWorldPixMap( *theGWorld ))) { RGBForeColor( &rgbBlack ); //** RGBBackColor( &rgbWhite ); //** OpColor( &rgbOpColor ); //** EraseRect( &(**theGWorld).portRect ); UnlockPixels( GetGWorldPixMap( *theGWorld )); } SetGWorld( previousGW, previousGD ); return( err ); } --------------------------- >From lipa@camis.Stanford.EDU (Bill Lipa) Subject: Thread Manager 2.0 Date: 21 Mar 1994 06:29:24 GMT Organization: Center for Advanced Medical Informatics at Stanford The PowerMac compatible version of the Thread Manager is included in the April developer mailing. Upon reading the documentation, I was surprised to find out that preemptive threads are not supported on PowerMacs. Does this really mean that any program that uses preemptive threads is not portable to the new machines? I wonder why they had to make this change. Bill Lipa lipa@camis.stanford.edu +++++++++++++++++++++++++++ >From leonardr@netcom.com (Leonard Rosenthol) Date: Mon, 21 Mar 1994 21:03:15 GMT Organization: Aladdin Systems, Inc. In article <2mjes4$md4@morrow.stanford.edu>, lipa@camis.Stanford.EDU (Bill Lipa) wrote: > The PowerMac compatible version of the Thread Manager is included in the > April developer mailing. Upon reading the documentation, I was surprised > to find out that preemptive threads are not supported on PowerMacs. Does > this really mean that any program that uses preemptive threads is not > portable to the new machines? > > I wonder why they had to make this change. > It has to do with the way the 68000 interrupt system works on the PowerMac. There is not a multi-level interrupt scheme, as I understand it, so they can't easily schedule the interrupts they way they do on the 68K. Leonard - ------------------------------------------------------------------------ Leonard Rosenthol Internet: leonardr@netcom.com Director of Advanced Technology AppleLink: MACgician Aladdin Systems, Inc. GEnie: MACgician --------------------------- End of C.S.M.P. Digest **********************