PT 7.1cs5 and RTAS VI

[Ray Lyon]

Does anyone know if the cs5 update fixes the dual processor problem with RTAS VI's?

Many users here on DUC have been using single processor mode to keep from having problems... of course, we'd all like to take advantage of the optimization for dual processors ... a feature PT7 was supposed to have from the start...

[Rail Jon Rogut]

I believe the VI's having issues aren't Digidesign's.. which seems to indicate it's not a Pro Tools issue but the 3rd party VI developer's issue.

Are you having any issues with multiple CPU's and Xpand! ?

Rail

[Ray Lyon]

I believe the VI's having issues aren't Digidesign's.. which seems to indicate it's not a Pro Tools issue but the 3rd party VI developer's issue.

Are you having any issues with multiple CPU's and Xpand! ?

Well, the VI's I use are supposedly PT7 ready (Ivory, Spectrasonics) all though I'm not as sure about Kompakt (v. 1.0.3). I did get a quit when I added Xpand! to a session that was in dual processor mode with the aforementioned plugs. So I switched to single mode and the problem went away. I have not tried using Xpand! alone with dual processors, however.

I am currently downloading Kompakt 1.0.8 which, being the latest version, may address any problems with PT7

The cs5 read me states a fix for quits in dual processor mode, but does not directly address the VI issue. I thought perhaps they might be related.

[axiom]

All the troubles I have had with RTAS VIs are using 3rd party plugins. When I use the Digi plugs like XPAND!, no problems at all. Unfortunately, I need all the 3rd party instruments to work. It would be nice if they all worked properly.

Cameleon 5000 doesn't even load on an instrument track, only on an audio track. I guess they haven't updated it for PT7 yet.

[quadcore]

Well lets summarize for a minute:
These Vsti's have worked on _every_ other plugin platform, and as standalones, for years
ie - Vst, Au, DXi
Digi makes their money from selling $3000 tdm cards that these plugins do not use.
Digi recently changed their Rtas handling, and it is _still_ not correct.
and you are saying this is not a Digi problem?

[Rail Jon Rogut]

and you are saying this is not a Digi problem?

Yes.. absolutely (not)! -- The developers are suppied an SDK (Software Developer's Kit)... and they're supposed to ensure their products are compatible. Multiprocessor programming is tricky... and some may not be familiar with coding for it. I would expect all of them to have beta tested their products with MP Macs running Pro Tools 7.x before releasing their products (or claiming they're 7.x compatible).

Digi's own VI's work fine - which shows that it can be done if it's done right.

Rail

[quadcore]

Hmmm ok, point taken, but how about running your Rtas plugs with this known issue (from compatibility page). The warning says issue is limited to low buffer sizes but I am seeing wierd cpu usage with any buffer size. So how do you code for a Rtas engine that is not working with multiprocessors?

"Low Buffer Size/Multi-Processor Issues with Pro Tools 7 on Mac OS X

There is a known issue with low hardware buffer sizes and the multiprocessor RTAS engine of Pro Tools 7 (HD, LE, and M-Powered). Specifically at buffer sizes lower than 512, multiprocessor setups of Pro Tools can show a marked INCREASE in CPU utilization as you enable more processors. While dual processor models also exhibit this behavior somewhat, it is more noticeable with 3 or 4 processors enabled on the Power Mac Quad G5.

Digidesign is aware of the problem, and is actively working on the issue.We have run a number of tests, and while we continue to investigate a fix, our tests have turned up a few situations where this problem is likely to manifest, and a workaround for those scenarios.

At buffer sizes 512 and higher, we recommend you use the maximum number of processors. More processors will give you more cycles to run additional RTAS plug-ins and more tracks with little additional overhead from Pro Tools' management of additional processors.

We recommend the following setting for existing or new sessions that require lower buffer sizes:

1. In "Setup/Playback Engine" lower "RTAS Processors" to "2 Processors".
2. If you still see errors, one or more of the following will reduce the CPU utilization below the error threshold:
* Make some plug-ins inactive
* Make some tracks inactive
3. If errors still occur, follow the same instructions with one processor enabled

Once you are mixing, you may use all processors, and restore any inactive tracks/plug-ins. You can then increase the HW buffer size to 512 or higher to prevent errors."


note this statement: "multiprocessor setups of Pro Tools can show a marked INCREASE in CPU utilization as you enable more processors"

This, at least, _is_ a Digi problem.

[PastaViking II]

OK, let's mention the elephant in the room:

RTAS was never great or reliable - it wasn't stable five years ago and it still isn't...

There, I've said it. Now can we please have AU or VST support?

[Ray Lyon]

HThere is a known issue with low hardware buffer sizes and the multiprocessor RTAS engine of Pro Tools 7 (HD, LE, and M-Powered). Specifically at buffer sizes lower than 512, multiprocessor setups of Pro Tools can show a marked INCREASE in CPU utilization as you enable more processors. While dual processor models also exhibit this behavior somewhat, it is more noticeable with 3 or 4 processors enabled on the Power Mac Quad G5....

This note seems to be for quad machines... what about those of us with dual G5's... What does Digi recommend as optimal settings given the current state of plug in updates?

[DigiTechSupt]

You should be able to set Dual processor machines to use both processors.

In very limited testing of cs5, I noticed some improvements when using 4 processors and RTAS instruments, though it was by no means an exhaustive test.

I know that engineering is working on the quad processor optimizations, but there is no specific info on when a release will be made available that completely tackles the problem.

In the meantime, I'm going to try to find time to run cs5 through it's paces to try to confirm if there are any verifiable improvements.