tyronehowe wrote:Blimey, Frodo, you always give such comprehensive answers! What would this forum be without you?!
A lot quieter?
tyronehowe wrote:M
But I think I might slightly disagree with you about this being a “very new interim technology” – I think this technology has been around for a while, even PLAY has been around for … over a year, I think?
Oh, of course it's been out for over a year, but that's still fairly new considering that the miracle machines, being the Intels, appeared in 2006 after several seasons of G5's stuggling to reach the 3Ghz mark. There has been chat about OSX's potential for breaking the 32-bit barrier for some time-- at least as far back as Panther. In retrospect, it appears that no one anticipated that the transition to real 64-bit addressing would be as protracted as it has been (or continues to be). But, it was only June 2007 when Apple recanted on its intentions to support 64-bit Carbon frameworks-- and it may be another year before we actually see Snow Leopard.
This means that the days of Universal Binary may be numbered, which in turn means that developers who intend to support Snow Leopard must follow stricter Cocoa protocols. It also means that PPC support will diminish. So, we're still in a bit of a gestation period with all of this. While the implementation of the co-host or co-server is probably "good enough" to release to the public as a stop gap, there may be limits to how far it could be developed given that Apple will eventually drop Carbon frameworks. The only thing I can think of to sustain further development of Carbon frameworks would be a market that remains more strongly dedicated to 10.5.x and PPC hardware who are more reluctant to adopt the Intel platform.
While the concept of a co-host or co-server that extends the memory management of a 32-bit host app is not new, it's time span on the market and in the hands of users is still fairly new, and the list of software making use of this technology is still fairly short.
tyronehowe wrote:
...What happens if I try to load a non- PLAY VI after I’ve filled the 3Gb up? Is PLAY clever enough to move some of what it was using in host memory out to the ousiao server? I find that very hard to believe, and incredibly complex if true. If PLAY does NOT do that memory reshuffling, then that implies that the order in which I add VIs to my project would be critical, i.e. load all non- PLAY VIs first to make sure they fit in the 3Gb. Ahh this sounds wrong.
Well now, let's see. Only the PLAY instruments will follow the ousiao, not non-PLAY instruments. It doesn't really matter given the same amount of data is loaded. What matters is how much physical memory is installed. The more, the merrier. Personally, I've never found it necessary to disable disc streaming. But, I also believe that one's success with PLAY hinges on it's Settings and Prefs. There may also be merit to the argument that since PLAY was born in the age of the MacPro that the software benefits from optimization on the newer architecture.
tyronehowe wrote:
I need to perform some more tests when I get a moment – I need to test in Logic as well just to check.
Indeed. DP only bundled VIs with DP5, so it's rather young at it. Separating DPs strengths and weaknesses from those of PLAY is a very important step in the testing process. Already, I've seen Logic's CPU usage run at about 25% that of DPs with the same data. That doesn't mean DP is bad. It just helps to identify behaviors unique to DP to distinguish them from those behaviors unique to PLAY and those unique to Logic.
tyronehowe wrote:
Ok – THAT’S the bit that’s giving me problems. The only conclusion I can really draw from this is that having PLAY use DP memory is faster (presumably because there is no extra inter-application communication needed), but IF you are using so many PLAY instruments that go over the 3Gb limit, then you will be using the ousiao server, so turn off disc streaming to try to speed things up. Still seems hit and miss though – because how do you ever know which PLAY instrument is using DP memory, and which is using ousiao server memory?
You add PLAY instruments one at a time and watch Activity Monitor.
tyronehowe wrote:
I think I’d like the option for it to permanently work with ousiao server memory (which as you know is effectively what VSL does).
Interesting thought. But, if one is to make use of signal processing as well, the ousiao will take over at whatever point the DAW host reaches its threshold. Once again, the more physical RAM one has installed, the more memory there is for ousiao to do its job,
But here's the wash: one would have to run a lot of fx and audio (as opposed to VIs) in DP to max out its 4GB limit. Even under the VSL method, the host will only use whatever amount of memory it needs. All other memory remains available for other processes. As an example, if DP only needs 500MB-2GB for audio and fx, then the remaining 2GB it might use if need is put on reserve by virtual memory and redirected where its needed.
This is quite different from OS9 where the user was allowed to manually reassign memory to various processes. It was not always efficient, but it was easier to understand.
tyronehowe wrote:
Of course maybe EW’s programmers aren’t as smart as VSL’s, so maybe the reason we have to have this disc-streaming / non disc streaming option is make up for this difference in efficiency. Hmm, that’s beginning to make more sense to me.
I think it may be that EW has come from an older world of technology where the NI engine dates back to at least 1999 with Reaktor and Transformator.
VSL is just younger. The VSL support of other engines was relatively short lived, but VSL also entered the game with a 550GB orchestra library. The limitations may have revealed themselves to the VSL team more quickly whereas EW still held interests in much smaller libraries-- until such time SO entered the picture. VSL also had the benefit of taking up the rear, so to speak, and developing according to long established limitations of generic audio engines.
tyronehowe wrote:
ah well maybe I guessed that you might just answer anyway because you are such a good sport about all this.
Just more of the curious sort-- I'd like to understand this stuff better myself.
tyronehowe wrote:
However, I think you are much more forgiving and understanding about this than I am
EW have been working on PLAY for a long time now and it still feels very unfinished. In fact, worse than that, it feels to me to be badly designed.
I lived through the first incarnations of PLAY, it has come a very long way. I've been through some very difficult times and would not hesitate to tell you if were not working. But after a miserable 2007 of incessant crashes and technical mishaps, PLAY really delivered the goods at least as far as memory addressing is concerned. I have mixed feelings about the VIs themselves, but that's another story.
While I've never tried PLAY on PPC, I have tried PLAY in both Tiger and Leopard on Intel and am fairly pleased so far with the results. Trust me: if it turns out to be unstable, I will let you know!
tyronehowe wrote:
EW’s advice is to keep checking Activity Monitor to see how much memory is being used? Sorry EW, but that’s just not right.
I prefer VSL’s method without a doubt. Yes I know it’s limited to just one extra process (and therefore to “just” an extra 4Gb), but it is a lot easier to work with (for me). And maybe VSL are working on a 64-bit extension as we speak.
Until 64-bit DAW hosts begin to appear on the Mac, we won't see a true 64-bit version of PLAY or VSL. That's the main hurdle right now, and there may be a stack of hurdle-ettes preventing that from happening.
But-- I wouldn't shun the Activity Monitor so quickly. It was while using VSL itself that I made liberal use of the Activity Monitor. I still use AM whenever I build new templates just to have a clear picture of available resources to construct such templates within reason.
tyronehowe wrote:
Well, Frodo, you and I really do get to discuss EW PLAY a lot recently. It certainly helps me understand things; the mere act of writing it down helps to crystallize my thoughts and understanding about EW PLAY. As I said earlier though, I am less happy about the state of “PLAY” than I think you are.
Welcome to the journey of Frodo. The road to Mt. Doom wasn't always full of good news, but it had its moments. We may have, in a manner of speaking, only made it as far as Rivendell where we sit in council.
At this point, it's going to be important to test PLAY in different DAWs. Even Garage Band is a worthy host, being closer to the core of Core Audio. Exploring various buffer and streaming settings of the host and of PLAY in combo will reveal much. Activity Monitor will tell the truth about your machine's threshold of pain. Knowing how much data can be run successfully in relation to the amount of physical RAM one has installed is another critical piece of the puzzle.
tyronehowe wrote:.. but the more we post and test, the more everyone can benefit.
If this info does not come directly from the developers, then it's really up to the users to get to the grass roots of what works best on their systems. I really believe with your system and memory that finding the right balance and combination of settings will be of great help.
That's why we're here!
