Aug 89 Letters
Volume Number: 5
Issue Number: 8
Column Tag: Letters
By David E. Smith, Editor & Publisher, MacTutor
Fabien Samuel
Paris, France
As always I read the March issue of your magazine with pleasure and interest. I
would like to share a comment about Randy Leonard’s 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 Randy’s 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) isn’t even needed, because GetFNum
automatically calls it before returning (IM I - 223).
Resource Fork Problem
Paul Onstad
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.
MIDI Problems
John Kaplan
Chicago, IL
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 wouldn’t 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 DC’s
in it so I declared all the variables as IMPORT’s in the assembler, and as variables of
corresponding types in the LSP interface file. I didn’t 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 you’re going to have to have space for your data somewhere anyway)
but that’s 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 it’s 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 doesn’t work, and try as I might, I can’t find
what’s wrong. I’ve been over my code 5 times and can’t find a typing mistake, and I
don’t have the expertise in interrupts or serial chips to know exactly what’s 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 don’t know about.
I was hoping you could provide some guidance. I am including all relevant code I used.
Of course, if it’s 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
what’s 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.)
Offending code:
outmidi := $0092;
txmidia(outmidi);
outmidi := $003C;
txmidia(outmidi);
outmidi := $0040;
txmidia(outmidi);
while button do
;
while not button do
;
while button do
;
outmidi := $0082;
txmidia(outmidi);
outmidi := $003C;
txmidia(outmidi);
outmidi := $0040;
txmidia(outmidi);
[Not being a MIDI expert myself, I’ll 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 Kirk’s
latest version. Kirk’s latest MIDI code wasn’t 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
Drew Steis
Herndon, VA
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
Computer’s 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.