Anomalies in DP5.12 and OSx 10.4.10

Frodo · Post by **Frodo** » Wed Jul 11, 2007 5:14 pm

Timeline wrote:I have found K2 seems to really load up the sys when multiple sounds are cued at once.

Try using more instances and breaking them up. Strangely, it helped me.

Interesting that this is the same advice that came from EW regarding PLAY-- to not load up one instance but rather use multiple instances with fewer patches in each.

Okay, so the workaround is understood-- but it seems to defeat the intent of having a multi-timbrel VI. The NI players placed an 8-patch limit on each instance-- so perhaps they know something we don't. That there are no more NI Players for the Intel has even deeper implications.

What's odd is that on the MacPro I've never had a CPU spike. While this is much more common on the G5, K2.1.x is a WHOLE lot more stable-- loads and saves much faster.

Incidentally, I need to track down the info regarding K2 loading in "ghost samples" where different patches use the same samples. The ghost samples are loaded into RAM in some way that overwhelms the system.

The one issue remaining that is not unique to K2 is when DP in the activity monitor shows 16,777,210.00 TB of actual memory. This number comes up when there are more than 3GB of samples loaded in any VI on my system-- and crashes only occur once this number appears. That number, incidentally is the exact same as the RAM access limit number under 64-bit threading. Why it's showing up now with 32-bit apps is beyond me.

I'm really starting to envy my friends who do not use VIs and are dedicated to audio-only. Those who have moved on to the MacPros are in hog-heaven right now.

jstaczek · Post by **jstaczek** » Wed Jul 11, 2007 9:04 pm

This may be of interest to folks on this thread.

I'm running DP as a sequencer on a dual 2.5 G5. It's communicating with a MacBook Pro which is using DP to host VIs. I'm running the following on the MBP (3G of RAM, more than the 2.5G I have on the dual G5).

18 instances of Vienna Instruments Special Edition
1 instance of Kontakt 2.2 (running all 16 instruments)
2 instances of M-Tron,
1 instance of ComboSister
1 instance of Oddity

G5 is running 10.4.9, MBP is running 10.4.10. Both machines have been VERY stable. I've been getting 2-4 minutes of music written per day with NO crashes on the MBP. I probably get one crash per week on the G5. MBP CPU hovers around 50% at 128 buffer.

Three observations:

1. The new VSL VI's use a special mode that runs OUTSIDE of the host's memory space, allowing each instance of the VI access to a full 3G, regardless of what the host uses. When you open the VI in DP, all it has a button that says "Show Window" which brings up a totally separate (non-DP) window for the VI controls. This seems to be a very effective strategy.

2. This is the most stable DP configuration I've ever used. I don't touch the MBP, and I can switch DP projects on the G5 very quickly. No VI loading, etc. But I do run only one sequence per DP project. The MBP becomes a kind of "super V-Rack".

3. DP's crashing seems to have a lot do with using the UI. The untouched MBP simply doesn't crash.

I'm planning to load the G5 up to the full 8G of RAM and switch it to be the "super V-Rack" machine and run DP as the sequencer on the MBP. I expect that this will provide enough VI horsepower for the time being. And if I need more, that'll be a good problem to have and I'll get another used dual G5.

This method does depend on two machines, but when I calculate the amount of time I spent futzing trying to get one machine to do the trick, the expense is more than justified.

Food for thought and one possible path to productivity which is what we're all after, no?

Frodo · Post by **Frodo** » Wed Jul 11, 2007 10:34 pm

Jason, this is great news indeed.

Earlier today, Timeline was asking about OSX running inside a shell. I couldn't answer that question definitively, but I learned about various types of shells within Tiger that allow developers to have a field day with apps, etc. It seems that the new VSL console at one time dominated the screen-- always on top. The shell outside of DP explains much in this regard. Fortunately, VSL changed things so that when you clicked on the DP window it went to the background.

This also makes running standalone rather moot if RAM outside of DP is being accessed.

Most impressive (to me) is that you were running a full wack of K2 samples. I'm pushing 2-3 partially loaded instances-- and have quite a few KS patches loaded in. (On a side note, EWQLSO Plat Bundle arrives tomorrow-- and I'm wondering if I'm just asking for more trouuble!)

I had a really good day today, though. K2 wasn't used at all!! LOL! The trade off is that I switched from EWQLSO back to Miroslav Philharmonik. Not the greatest sounds but good enough to work with when preparing scores for Finale rather than audio mixes for CD.

18 instances of VSL-- how big are your matrices?

jstaczek · Post by **jstaczek** » Wed Jul 11, 2007 10:48 pm

18 instances of VSL-- how big are your matrices

They're 50-150Mb each. I run one per instrument/section. Flute ensemble + solo flute, horns a4 + solo horn, etc. I'm only running Special Edition, so the matrices for strings, for example, aren't huge: I don't have all the articulations I'd like!

Frodo · Post by **Frodo** » Thu Jul 12, 2007 12:44 am

jstaczek wrote:
18 instances of VSL-- how big are your matrices
They're 50-150Mb each. I run one per instrument/section. Flute ensemble + solo flute, horns a4 + solo horn, etc. I'm only running Special Edition, so the matrices for strings, for example, aren't huge: I don't have all the articulations I'd like!

Yeah, I get stuck with a shortage of artics as well. I can get a monster string section loaded, but that's about it. I'm going to have to try some more sample load tests--

... and someone pointed out that there's a voice allocation feature! Didn't know about it until today! Duh! Alt-Apple-P was what I was told to use with the VI console on top, although I wonder what they really meant by ALT, being that it might require another modifier (shift-option?). Hmm. I'm going to spend some time playing around with VSL tonight just to see how much 5.12 can handle-- then will try the same setup in Logic for the sake of comparison.

I'm just so happy that my system is working okay without K2 (but sorry that K2 brings it to its knees just when I need it the most).

zed · Post by **zed** » Thu Jul 12, 2007 9:05 am

Hey fellows,

I am still in 10.4.8, but I have a question about 10.4.10 and I didn't want to start a new thread because it is not really DP related...

I'm just wondering if Apple has fixed the copying files issue where the Finder simply quits the process of copying files if it encounters a single file it cannot copy. It is so ludicrous that when you are doing a backup of numerous gigabytes of information and nested folders, that all of a sudden the operating system quits the copying process because it discovered a file that it doesn't like. That leaves the user to have to carefully figure out what was copied and what wasn't. And it makes doing backups such a pain in the ass. IMO, Finder should just keep copying everything it can and then give an error report at the end of the process.

I can't believe that we're several YEARS into OSX and the Finder still has these ridiculous deficiencies.

And BTW, the file it doesn't like is usually not faulty... it is just that the Finder tripped while copying it, I suppose.

Anyone with good news?

bjornln · Post by **bjornln** » Thu Jul 12, 2007 9:27 am

zed wrote:Hey fellows,

I am still in 10.4.8, but I have a question about 10.4.10 and I didn't want to start a new thread because it is not really DP related...

I'm just wondering if Apple has fixed the copying files issue where the Finder simply quits the process of copying files if it encounters a single file it cannot copy. It is so ludicrous that when you are doing a backup of numerous gigabytes of information and nested folders, that all of a sudden the operating system quits the copying process because it discovered a file that it doesn't like. That leaves the user to have to carefully figure out what was copied and what wasn't. And it makes doing backups such a pain in the ass. IMO, Finder should just keep copying everything it can and then give an error report at the end of the process.

I can't believe that we're several YEARS into OSX and the Finder still has these ridiculous deficiencies. And BTW, the file it doesn't like is usually not faulty... it is just that the Finder tripped while copying it, I suppose.

Anyone with good news?

I have never had that happen to me... ever.
Have you any logs that tell you what happened ?
So the issue..... well no... or yes or hu ?
(in other words it doesn't say)

Edit:
Unless you're talking about copying to/from a windows machine..
then: NO. I guess apple could solve it in a nicer way. But, this is simply because it's unix vs. Win... Windows have a finer granularity in their permissions system, which unix simply doesn't have. And I think it would be a massive job to rewrite the permission-system and it probably cause more problems than they fix.

/B

zed · Post by **zed** » Thu Jul 12, 2007 9:47 am

bjornln wrote:I have never had that happen to me... ever.
Have you any logs that tell you what happened ?

Hmmmmm. This often happens to me, despite the fact that my drives are supposedly in good condition. I come back to the computer to see if the files have finished copying, and an error message says something along the lines of "couldn't finish copying because a problem was encountered with the file xyz." I think today it said Error -36 (which is an I/O error). I'm copying files via firewire 800 to an external drive.

I have no idea if there are any logs kept of this kind of thing. Do you know where I would look for that?

bjornln · Post by **bjornln** » Thu Jul 12, 2007 1:54 pm

zed wrote:
bjornln wrote:I have never had that happen to me... ever.
Have you any logs that tell you what happened ?
Hmmmmm. This often happens to me, despite the fact that my drives are supposedly in good condition. I come back to the computer to see if the files have finished copying, and an error message says something along the lines of "couldn't finish copying because a problem was encountered with the file xyz." I think today it said Error -36 (which is an I/O error). I'm copying files via firewire 800 to an external drive.

I have no idea if there are any logs kept of this kind of thing. Do you know where I would look for that?

Apps=>Utilities=>Console
klick the little console icon on the leftside and all the logs appear (or dissapear if they were allready shown).
You'd probably want to start with the system-log and console log.
It will show you Errors and messages.
If you poke around a little you will find a DP log as well.

/B

zed · Post by **zed** » Thu Jul 12, 2007 2:10 pm

bjornln wrote:Apps=>Utilities=>Console

Thank bjornin. I did find the following errors around the times of the incidents, but they don't really tell me very much (not to mention that my dashboard is disabled).
The files did copy properly on the second go around... so the hiccups just caused me a lot of inconvenience double checking things and recopying.

zed's system.log wrote:Jul 12 08:34:23 PowerMac-G5 cp: error processing extended attributes: Operation not permitted
Jul 12 08:40:45 PowerMac-G5 dashboardadivsoryd[5113]: fetch: unable to fetch data from read stream while fetch advisory list
Jul 12 08:40:45 PowerMac-G5 dashboardadivsoryd[5113]: fetch-parsers: unable to fetch data from read stream
Jul 12 08:51:56 PowerMac-G5 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mdimportserver: Corrupt JPEG data: 67495 extraneous bytes before marker 0xd9\n

At this point I won't worry about it anymore. I just wish this whole backup routine would run more smoothly. There should be no need for me to spend several hours babysitting this process everytime I want to do a major backup. Drives me nuts!

bjornln · Post by **bjornln** » Thu Jul 12, 2007 3:19 pm

zed's system.log wrote:Jul 12 08:34:23 PowerMac-G5 cp: error processing extended attributes: Operation not permitted

Here's you perp... What are you using to copy to / from ?
cp is the copy operation under unix..
"extended attributes" is what unix usually can't handle (or have trouble with)

Have these files been ftp:d ?
What program have "touched" the file ?
(backup program, FTP, other program except finder)

Do you have a SAN or NAS server ?
windows PC ?

Best
/B

zed · Post by **zed** » Thu Jul 12, 2007 4:13 pm

bjornln wrote:Here's you perp... What are you using to copy to / from ?
cp is the copy operation under unix..
"extended attributes" is what unix usually can't handle (or have trouble with)

Have these files been ftp:d ?
What program have "touched" the file ?
(backup program, FTP, other program except finder)

Do you have a SAN or NAS server ?
windows PC ?

Hey bjornin. Nope, I have none of those servers or a PC. I was just copying files from my G5 to an external drive. I think one of the files was an mp3, and another was a PC font I had stored in some folder. But I have lots of each of those file types... and the problem files did copy the second time around. It's definitely possible that some FTP program touched the files, especially the mp3. Only happened those 2 times this morning. Copied lots of other stuff in the hours that followed and didn't have copy issues... other issues... but not copy issues.

Perhaps I ought to run some sort of utility app to clean up those "touched" files? Would be nice not to have to face this again next month.

Thanks for your input today. I'm glad I know about those console logs, now.

mhschmieder · Post by **mhschmieder** » Thu Jul 12, 2007 10:49 pm

OK, sorry if this topic has moved on beyond the original topic, but as I loaded MasterWorks Limiter tonight and noticed flakey behaviour similar to what was reported in the original post, I thought I should report my findings.

I am not yet getting a repeatable scenario, but it does seem that order of operations matters, and that I have to avoid certain ways of working with the plug-in in order for my edits to show up in the graph. But now I don't remember what I did when I first opened it that didn't show up, as I'm having my edits show up now.

I tried some of the presets, and one or two of them made the graph go all-white (not even all-black!), and initially did not accept edits to the preset in terms of visual feedback. Reloading the same preset (the first one under the 24-bit preset folder) generally worked -- maybe the third time at worst.

I'm not too worried as it seems to be a timing issue in the GUI in terms of responsiveness and how quickly one clicks from one part of the GUI to another. It's certainly hard to read and I don't remember the visual being so fuzzy before, but as I said earlier, I stopped using the MasterWorks plug-ins (except for the EQ) last year after getting dedicated hardware. So maybe I just don't remember how hard it was to read.

blue · Post by **blue** » Thu Jul 12, 2007 11:17 pm

zed wrote:I just wish this whole backup routine would run more smoothly. There should be no need for me to spend several hours babysitting this process everytime I want to do a major backup. Drives me nuts!

I would recommend getting a synchronization utility like Chronosync or Personal Backup to do backups. The finder is hopelessly limited when it comes to copying files, and it cannot do synchronization or scheduled backups. Time Machine should help, but in the meantime you can get something for $30 that will take all your backup headaches away.

http://www.econtechnologies.com/site/Pa ... rview.html

http://www.macupdate.com/info.php/id/97 ... -backup-x4

michkhol · Post by **michkhol** » Fri Jul 13, 2007 8:19 am

bjornln wrote:
zed's system.log wrote:Jul 12 08:34:23 PowerMac-G5 cp: error processing extended attributes: Operation not permitted
Here's you perp... What are you using to copy to / from ?
cp is the copy operation under unix..
"extended attributes" is what unix usually can't handle (or have trouble with)

/B

FYI: Finder doesn't use cp for copying and it does support extended attributes. Actually it comes from older Mac OS and is totally unfitted for large data transfers. I would also recommend using a dedicated backup software.