Hi Darcy,
The points you brought up regarding Temp files and RAM Disks got me thinking. I'm wondering now if this overwrite bug has to do with how RAM intensive Finale is....and especially with all the saving features (auto save, backups, temp files...) Since the overwrite bug occurs under different circumstances (task wise), the common denominator in my opinion may have to do with how Finale is working with the OS and hardware in ones computer. I am also very curious as to how Finale is handling temp files.
I'm now suspecting that when one has many files open at the same time, (or in my case, when many people are working off one server) and auto saves are happening, along with regular saves and the whole temp file thing that Finale requires a ton of RAM, perhaps more so than other apps that don't have some of these features or ways of dealing with temp files (sorry if this seems obvious)
The way that OS X deals with memory or lack thereof is interesting. When the OS is out of RAM it starts to copying data from RAM to the Hard disk (this is called paging) The file that the OS copies to on the hard disk (I should be more specific...boot disk) is called a...don't laugh...a swap file. This process is the virtual memory part of OS X.
So, I'm wondering if there is some sort of confusion somewhere with what is getting copied to/from what when the system resources are taxed thus creating the Overwrite Bug. Interestingly enough...low system resources, either RAM or hard disk space, can also cause problems with certain apps, depending on how/when the access their preferences, not saving Preferences correctly or having prefs being reset to "default" totally or partially after the app is relaunched.
This may explain why Finale is faster after a restart and why it seems that temp files are becoming bloated/corrupted after a long Finale session. It may not be the files themselves but rather that more paging has occured over a long session as OS X tries to juggle memory resources.
To test this, you can try this...open your terminal application and type "top" (no quote marks) You'll see something that looks like this at the top of the window. ****when you are done, to exit this terminal process, type ctrl-C and then you can quit the terminal app.******
Processes: 50 total, 3 running, 47 sleeping... 131 threads 11:52:30 Load Avg: 2.45, 1.30, 0.55 CPU usage: 27.3% user, 29.7% sys, 43.0% idle SharedLibs: num = 110, resident = 23.3M code, 2.80M data, 9.76M LinkEdit MemRegions: num = 5306, resident = 67.2M + 11.8M private, 53.5M shared PhysMem: 65.7M wired, 99.8M active, 109M inactive, 275M used, 364M free VM: 3.03G + 74.4M 15476(0) pageins, 0(0) pageouts
The two lines one is concerned with are the bottom two....these are Physical memory and Virtual memory (VM) Look at the last numbers of each line
PhysMem: 65.7M wired, 99.8M active, 109M inactive, 275M used, 364M free VM: 3.03G + 74.4M 15476(0) pageins, 0(0) pageouts
You should have plenty of Free PhysMem and a low pageouts number...0(0) means that my RAM has not been exhausted as of yet and therefore paging has not yet occurred. (I got these numbers after a restart with only a couple of apps running.) If one has enough RAM in the machine, free space will obviously be high and the pageouts will stay low...if there is not enough RAM, then the opposite will be true.....(i.e. 7.7M free for PhysMem and 876543(0) for pageouts for example) I might suggest running this terminal command after you have been visited by the Overwrite Bug.
However, all this is not to say that Finale isn't contributing to the problem if this whole memory thing holds water. As I mentioned in the beginning of this post, I'm curious as to how Finale uses RAM, if it is efficient or not and how much more RAM is needed with features like auto save set up.
-K
Hey Allen & co,
One more thing:
I noticed a *drastic* performance improvement when I quit and restart Finale compared to what I was getting during the session where the File Overwrite bug hit, despite having exactly the same set of files open as I did before. Redraws were easily twice as fast.
Could there be a problem not only with the File Overwrite bug, but with the Finale Temp Files getting bloated/corrupted over the course of an extended Finale session, causing performance degradation AND problems such as the File Overwrite bug?
Please let me once again repeat my request to do away with temp files and instead have Finale store that information in RAM -- at least as an option. (We used to be able to do that in OS 9 with a RAM Disk, but RAM disks aren't effective in OS X.)
It seems like many of the stability and corruption problems in Finale have to do with the way it handles temp files, which are a bit of an anachronism in any case. Perhaps some of these problems could be solved by using RAM instead of disk space?
- Darcy ----- [EMAIL PROTECTED] Brooklyn, NY
On 19 Jan 2005, at 08:07 AM, Darcy James Argue wrote:
Damn -- I thought I had dodged the problem, but I got bit by it anyway -- on a different file!
Here's the MacSupport note:
Hi Allen & co.,
Just an update -- when I noticed the printing problem with the last file, I tried opening a second instance of the file (without quitting Finale), which fixed the problem. However, I continued to work without quitting Finale, until just a moment ago, when it abruptly became impossible to select anything with any tool.
I went through each file one by one and manually saved it and closed it. Then I quit Finale. When I relaunched Finale, the file I had been working on when the problem with selecting things occurred had been replaced with different content. I have attached it here:
[attachment deleted]
It was originally a chorus part with piano reduction, but it's been replaced with the content of the Harp part for this piece. I don't know if you can glean anything from this file, but take a look and see if it tells you anything.
For comparison purposes, here is the most recent auto-saved version of the same file:
[attachment deleted]
Let me know if I can give you any other info that might help pin this down.
Cheers,
- Darcy ----- [EMAIL PROTECTED] Brooklyn, NY
CC: of message I sent to Allen and MacSupport, minus the attached files:
Hi Allen, guys,
Allen, I know you're going to NAMM but hopefully you get a chance to look at this when you get back.
I think I may have an instance of the File Overwrite bug in action. This is in Fin2005a. I have 22 documents open. The frontmost document -- "08 The Gallows 2005.mus" -- is *displaying* the *content* of that file (a score), but when I go to print, the file that actually prints is a different (also currently open) file -- "WitCan - 002 Percussion 2005.mus" ( a part). I have confirmed this printing error twice.
I am sending you both files in their current states. When you open "08 The Gallows 2005.mus," does it look like a score, or a part? When you print it, does the printout match the screen contents, or does it print a percussion part instead?
UPDATE: when I open a second instance of the part, it prints correctly. I'm going to save the problematic instance under a different name and see what happens.
- Darcy ----- [EMAIL PROTECTED] Brooklyn, NY
_______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
_______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
-- Karen Guthery _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
