What you describe is certainly within the realm of possibility. I spent a bit of time earlier in my career modeling the behavior of large-scale mainframes, and this involved a branch of science called "queuing theory". There very definitely can be "knee of the curve" phenomena where everything is just fine until you hit a certain point, and then things immediately go very, very bad. I wouldn't have thought that 6GB would be a limit, and it seems that on my system when things go bad, they virtually grind to a halt.
Nonetheless, I have been investigating an upgrade to this system, not for Finale, but to run my DAW software faster. I'll probably completely replace it with quad core and either 16GB or 32GB. So the problem may very well go away at that point. It is encouraging to hear that most people do not really have big problems in this area. On 9/13/2013 11:57 AM, Phil Buglass wrote: > I am also running win7 64bit, but I have 16GB of > RAM in there. I don't think *that* would make > quite as much of a difference as we are seeing, > though. I suppose it is possible that with > windows, plus finale and stuff running, you are > hitting a point where your memory is full and it > starts paging madly to try and process the rest > of the file. If this is something you do a lot, > then it may well be worth investing in a few more > GB of RAM. It would be a fairly cheap > experiment, and just *could* make all the difference to you. > > I guess a test would be to time an attempt, then > kill off as many background and system processes > as you can get away with, and time the same thing > again. Unless the memory limit is enforced by > finale, that should show quite a difference. If > the limit *were* enforced by finale, then I would > probably be getting the same result regardless of my extra RAM. > > Phil. > > At 11:35 AM 9/13/2013, you wrote: >> I don't think the speed of my machine is an issue. It is a dual core >> AMD running Win7 64-bit, with 6GB of physical RAM. There are certainly >> faster machines around, but this one is feast enough. The first 75% of >> the file is generated very quickly, then it grinds to a halt. I had >> this same problem on Finale 2011, and I mostly use 2012 now. >> >> I have given up hope that it will be fixed on 2012, but I do expect that >> the new Finale should have a big emphasis on DAW integration and >> rendering of audio files. >> >> >> >> >> On 9/13/2013 6:52 AM, Dennis Bathory-Kitsz wrote: >>> I've observed that the process has several >> stages: the initial 'scan' (which >>> is what also happens before ordinary playback with VST and human playback), >>> what appears to be a compilation of the actions into a temporary file, and >>> saving the compiled information into the >> final audio file. Each stage is shown >>> -- a dialog box, then a percentage on the >> status bar, and finally the progress >>> bar on the status bar. >>> >>> It can fail due to various bugs, but that's >> mostly the first stage (and also >>> fails the same way on human playback). If the >> file plays back all the way, it >>> should also save all the way. It's a fairly intensive process, though, >>> demanding lots of CPU and memory, so if your machine is older, slower, or >>> 'underpowered', it's going to do a lot of >> extra work swapping information on >>> and off the hard drives. >>> >> >> _______________________________________________ >> Finale mailing list >> [email protected] >> http://lists.shsu.edu/mailman/listinfo/finale > > “Outside of a dog, a book is a man’s best friend. > Inside of a dog it’s too dark to read.” Groucho Marx > _______________________________________________ > Finale mailing list > [email protected] > http://lists.shsu.edu/mailman/listinfo/finale > > > _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
