Aug 89 Letters
By David E. Smith, Editor & Publisher, MacTutor
As always I read the March issue of your magazine with pleasure and interest. I would like to share a comment about Randy Leonards article, How To Write a Font Tool for MPW. To start with, all my congratulations for giving a very clear presentation of the matter. I think anybody who reads the article now has all the material to easily start writing his own MPW tools. I just have a comment about the use of SetResLoad(false): as stated in IM, you should SetResLoad(true) as soon as possible after calling SetResLoad(false), or you may be asking for trouble. Although there is no problem in Randys program if it has a normal exit, it seems SetResLoad(true) will not be called when the program terminates on an error condition, and this might be a problem.
It appears the only call in the program that might trigger Resource loading is GetFNum, so I would personally bracket this call with SetResLoad(false) and SetResLoad(true). In that case SetResLoad(true) isnt even needed, because GetFNum automatically calls it before returning (IM I - 223).
Resource Fork Problem
St. Paul, MN
I enjoy your articles of Pascal code but have never come across an example which would lead me out of the problem that has stopped my application dead in its tracks.
1. I wish to maintain data in both forks of an applications HFS data file.
2. HFS provides only one Resource Manager call which considers the location of the file for subsequent resource calls, i.e., OpenRFPerm.
3. However, when the user performs a Save or Save as the existing file must be erased with FSDelete. Create then follows to create both forks of the file and the revised data is written to the data fork. The previous resource fork data is temporarily saved in memory by the application. The resource fork of the new file is now empty.
4. After the new data fork has been filled. A call to OpenRFPerm is made to open the empty resource fork with the intention of using AddResource to place the memory-saved resource data back into the revised file. But, OpenRFPerm returns an unsuccessful -1 because of ResError -39 (logical eof encountered on the empty resource fork).
Without a valid refNum from OpenRFPerm there appears to be no way to communicate back to the application the location (folder, etc.) in which the resource data should be restored on disk. The existing refNum was lost because the resource fork had to be closed before FSDelete--otherwise the file was busy and could not be deleted.
Additional (if of some use): DetachResource was used just before the file was erased in order to hold the resource data in memory while the actual resource (and data) file was deleted.
If you can provide any examples or information, it would greatly be appreciated.
I have been following your articles in MacTutor for some time, but have only recently been able to try your MIDI routines. I was hoping you wouldnt mind a few comments and questions that came up for me as I worked.
First, I know your code was meant for the MDS assembler and LSP version 1, but I was using MPW for assembly, and had to use LSP version 2. (Version 1 cannot link MPW object files.) I found that LSP v2 would not accept an MPW object file with DCs in it so I declared all the variables as IMPORTs in the assembler, and as variables of corresponding types in the LSP interface file. I didnt really understand why people objected to the use of A5 variables in the first place (since if your going to use MIDI in an application youre going to have to have space for your data somewhere anyway ) but thats not the point. The point is that after framing everything in PROC and ENDPROC directives for MPW and moving the blocks around to avoid forward references, the whole thing compiled and linked fine. The only other thing worth mentioning is that MPW assumes when a variable is imported that it is referenced through A5, so there are no explicit A5 references for the variables. (You probably know all this already, but I mentioned it just in case.)
The next snag I ran into was in testing the routines in LSP I wrote a little program that writes incoming MIDI information in the LSP text window. This was a big mistake, as LSP v2 seems to reserve the right to move your code around in memory as it calls graphic operations to update its text window. After the ten or fifteen crashes it took me to figure this out, I rewrote my code so I made my own window, and drew the MIDI information in with drawstring. (And locked the CODE resource for the LSP project in ResEdit, just to be on the safe side.) Finally RxMIDIA worked like a charm.
Then I wrote a simple sequence in my test program that sends a note on, then a note off for the same note. This just doesnt work, and try as I might, I cant find whats wrong. Ive been over my code 5 times and cant find a typing mistake, and I dont have the expertise in interrupts or serial chips to know exactly whats going on to debug it. I was thinking there might be another compatibility problem with LSP v2, or a problem with porting the assembly code from MDS to MPS that I dont know about. I was hoping you could provide some guidance. I am including all relevant code I used. Of course, if its too much trouble to slog through all my code to find bugs, any hint you could give me would be greatly appreciated--even so basic as how to start figuring out whats wrong myself (chip manuals and the like?). (By the way, the hardware I used was a Mac Plus with both a Southworth Jambox 4 and an Assimitation MIDI Conductor. When I tried TxMIDIA, I got no light on the Jambox panel, no response from my synthesizer, and no message on my Yamaha MEP4 MIDI monitor--meaning either no recognizable message was sent or no message at all.)
outmidi := $0092;
outmidi := $003C;
outmidi := $0040;
while button do
while not button do
while button do
outmidi := $0082;
outmidi := $003C;
outmidi := $0040;
[Not being a MIDI expert myself, Ill leave this up to any MIDI experts out there. But Kirk Austin did an update to his MIDI routines for an article in May 1989. After a quick look, I did notice a couple differences between the code you sent in and Kirks latest version. Kirks latest MIDI code wasnt published due to space limitations. The code is on the source code disk (#44) if you wish to order it. --Ed.]
Powerful Math Libraries Available With Language Systems FORTRAN
Language Systems Corporation announced that powerful math libraries from the Numerical Algorithms Group, Inc. (NAG) are now available for use with Language Systems FORTRAN. The mathematical library of scientific and engineering subroutines has not been available on the Macintosh until now.
NAG is a well-known international producer of scientific and engineering subroutines for supercomputers, mainframes and high-end workstations, said Rich Norling, chairman of Language Systems Corporation. Now, for the first time, Macintosh II users will be able to access the same algorithms used on supercomputers. NAG has made 172 of the most frequently used subroutines available in one package for the Macintosh II. This is a substantial portion of the NAG FORTRAN Library and provides broad coverage of the principal areas of mathematics and statistics.
Karl Knapp, Technical Manager of NAG, called the availability of the NAG Workstation Library for Language Systems FORTRAN on the Macintosh II a significant development, particularly for engineers who find themselves coding mathematical formulas over and over again from scratch. The library should free them up to get on with their real work.
The NAG Workstation Library offers subroutines for a wide range of mathematical applications including matrix operations, optimization, linear algebra, time series analysis and many others. The software is of particular value in projects for aerospace, energy production, chemical manufacturing, electronic design, and other areas where advanced mathematics are required.
Language Systems FORTRAN was the first FORTRAN compiler to be based in the Macintosh Programmers Workshop (MPW). The compiler is full ANSI Standard FORTRAN 77 and has the most VAX-compatible extensions on the Macintosh. It has the full capabilities of the Standard Apple Numeric Environment (SANE), Apple Computers implementation of IEEE Standard 754 for Binary Floating-Point Arithmetic.
Language Systems FORTRAN Version 1.2.1 can be acquired from APDA. The NAG Workstation Library can be obtained from Numerical Algorithms Group, Inc. 1400 Opus Place Suite 200, Downers Grove, IL 60515 (312) 971-2337.