Bugs? East West PLAY crashing DP5.13 too much!

[hrw]

still been finding Goliath play crashing DP especially when i am trying to edit MIDI continuous data such as velocities etc. also SD2 has been instantly crashing DP as soon as i try to load a MIDI performance. this SD2 prob is on my Mac Pro 2x2.66 w/5gb ram, Tiger. MIDI editing crashes happen on both my Mac Pro and MacBook. Incidentally. I have the latest updates of PLAY, Goliath and SD2 installed. Are these just Play bugs with DP??
Help?

[mhschmieder]

No; they happen in DP6 and in standalone mode as well.

I am having better luck with PLAY in DP6 than either in DP5.13 or in standalone mode.

As this improvement is specific to DP6, I don't think it's related to the latest PLAY update last week, which followed closely on the heels of another one a week or so before.

The fact that the updates are coming rather quickly now, probably means they are putting more focus on stability, after maybe being distracted for awhile by developing new sample-based products and porting old ones.

My biggest problem with PLAY is that I can load a maximum of two instruments (and not at the same time) before it crashes. I don't know why replacing an instrument would not first free up all resources, but I have to restart PLAY, to be on the safe side, when I change the instrument (.ewi file) that it points to.

At least in DP6 this is an improvement over DP5.13, where I had to restart DP or at least unload/reload the project file each time (and that's even with PLAY disabled in the VI stack).

[haydnwalker]

Thanks for that mhschmieder. Yeah i really hope they sort all this out soon. After all the hype and excitement of the PLAY revolution, its not much use when it crashes so easily rendering unfriendly and workflow restrictive. Suppose we will have to be patient. Did you tell East West about your issues?

[Frodo]

It really sounds like the issues with PLAY and other VIs may be related to DP in general, unfortunately. In some cases, DP6 appears to be friendlier. In other cases DP5.1x appears to work better with the same VIs.

The hard part is determining whether it's a VI problem or a DP problem. If, for example, the VI works everywhere else except for DP then one item that may be contributing to the problem *could be* the MAS Audio Units Bundle. If EW has met a certain AU protocol standard that works with basically every DAW that is AU compatible, then the process of getting the AU to wrap to MAS reliably is a MOTU issue.

That's not to overlook the very real possibility that PLAY is still a young engine and SO under PLAY is younger still.

There could also be a bump in the road where OSX stands between PLAY and MAS. It's very hard to tell.

From what I've seen so far, DP6's stability concerns are independent of PLAY. I will also add that I've been able to get a substantial amount of Platinum Plus loaded into DP6 and into Logic 8-- substantial, meaning ALL of the master keyswitch patches in the 16-bit version which access about 36GB of RAM.

One thing that many people are missing is that PLAY in mock-64-bit memory addressing mode doesn't really come to life unless you have more than 6 GB of RAM installed. Otherwise, it's best to use PLAY as a 32-bit plugin.

According to EW:

We recommend:

1. loading up Play into multiple instances inside your host,

2. set to "Stream From Disk" until you are nearing the limit of your *host's* Ram allotment,

---we don't recommend going over 3GB for stability reasons (you can verify this in the Activity Monitor utility).

3. Once you are nearing this 3GB limit, start opening NEW instances and load the rest of your instruments into RAM by **unchecking** the "Stream From Disk" setting.

To this I'll add that if you choose stream from disc, then raise your engine level under your PLAY VI's SETTINGS menu. Make sure that your PLAY buffer matches the buffers in DP and keep in mind:

If you are running large amounts of samples, you will have to deal with a larger DP buffer and consequently a larger PLAY buffer... even if that buffer is at 512. If that size is too large for tracking, then a smaller block of samples should be used at a time so that the buffer size can be reduced.

Basic rule of thumb:

Be aware of loading more plugins and VIs than 75% of your physical RAM.

If you have 2GB, then 1.5 GB is your benchmark.

If you have 4GB, then 3GB is your benchmark.

etc.

More samples *can* be loaded, but there's no predicting how virtual memory will handle things. Under circumstances the results can be surprisingly favorable. On the contrary-- well, you know.

[mhschmieder]

Yep, all good advice, but the strange thing is that since Goliath is a catch-all Virtual ROMpler, the samples are quite small (compared to stuff like Prominy PCP80, which I have no trouble loading and running). So even on my piddly G4 iMac, it doesn't even come close to the memory limit, compared to stuff like B.F.D., VSL, Prominy, Scarbee, etc.

[tyronehowe]

Hi Frodo

Thanks for displaying that information from EW – but I must say it is odd.

… so EW are saying use disc streaming until you are near the memory limit of your host and then switch over to non-streaming?

Why do you think they would say that? Is there something inherently better in PLAY for streaming over non-streaming? If non-streaming works fine, and there is plenty of RAM, why not non-stream everything for (presumably) better performance? Obviously I’m not asking Frodo these questions, but just musing aloud! What EW say doesn’t make a lot of sense unless there is something very quirky with their PLAY engine.

I still haven’t received EWSO, but I am itching to try it out.

[Frodo]

VSL is the only other major VI afaik that would be comparable in how it uses RAM. I wouldn't doubt that VSL just my be cleverer at it that PLAY.

However, there is a process called "ousiao" that appeared in Activity Monitor. The reason why this rather inconspicuous process caught my eye was that of all of "My Processes", DP and this little thing showed very curious numbers. DPs real memory came in at 1.46 GB, which is probably the equivalent number you are seeing. Even DP's virtual memory topped out at 2.86 GB.

However, "ousiao" ran only when PLAY was running. Its virtual memory exceeded that of DP's coming in at 2.57 GB. The aggregate VM is 5.43 GB. Them's a lot of pancakes!

I should also say that I noticed this for the first time with engine version 1.0.079 in Leopard. The only PLAY VI I have in Tiger is FabFour, so I'm now curious to see if this enigmatic "ousiao" appears in Tiger's Activity Monitor because I don't remember seeing it before when I had all of FabFour loaded at once.

… so EW are saying use disc streaming until you are near the memory limit of your host and then switch over to non-streaming?

More accurately, as you near 3GB add more instances and then *try* switching over to non-streaming if performance feels unstable. Even more accurately, if your machine has less than 4GB then your host will be cut short of its *designed* limit. As a result, PLAY will be working under a handicap where it's looking to access more RAM which just isn't available. That's why I wanted to stress that the threshold was 3GB --or-- 75% of your physical RAM ***whichever is smaller***.

Why do you think they would say that? Is there something inherently better in PLAY for streaming over non-streaming?

It's because of PLAY's method of memory addressing which is along the same lines as VSL's. This is very new interim technology that deals with the gray area of RAM limits that bring our machines to their knees and keep certain kinds of resource-needy software from running effectively. We've been watching full tilt 64-bit apps "not arriving". Necessity is the mother of all invention. Hence, we're seeing this multi 32 coding instead of honest 64-bit because most major DAWs are still 32-bit.

For strict 32-bit VIs, the method is clear. OSX, the DAW, and ALL plugins draw from the same physical memory. What OSX doesn't use, DP uses up to 4GB or so. All plugins, audio, and VIs share DP's memory.

With PLAY the first 3GB or so appear to operate within the host. Subsequent *plugin* instances somehow are handled by this "ousiao" server, allowing for all the convenience of running a standalone instance except as a plugin. The downsides to running standalone is that you can (generally) only run one instance and not all standalones support rewire.

On the VSL side, there is an independent server running, but VSL has figured out how not to use very much of the host's memory at all.

For non-streaming, if you have 32 GB of RAM you can likely load a humongous orchestra and have a much more responsive system simply because RAM is much faster than streaming and your hard drives and virtual memory are not working overtime.

If non-streaming works fine, and there is plenty of RAM, why not non-stream everything for (presumably) better performance?

They've given options to suit different users. To stream or not to stream. That is the question. Whether it is nobler in the mind to suffer the slings and arrows of calling tech support in the face of their outrageous fortune... yadda-yadda

Depending upon how much RAM you have, non-streaming may simply work better.

I’m not asking Frodo these questions,

woopsie...

... but just musing aloud! What EW say doesn’t make a lot of sense unless there is something very quirky with their PLAY engine.

Quirky, or simply "peculiar", the latter being perhaps less bad and more akin to "different". Few companies tell you all the "why's". They're pretty good at telling you what you *can* do, but good luck with gleaning the "how's".

PLAY's method seems a little more old-school in that its Settings and Prefs bear more in common with Kontakt, among other VIs. VSL doesn't offer users engine customization options. Memory addressing is much more self-governing. If VSL needs more memory it seems to know on its own how to go about parsing that memory. PLAY will get to a point and then tell you that it couldn't do what you wanted because of the way the prefs are set. Somehow, the user has to figure out what it is that PLAY needs.

I've not figured out which method I prefer.

In any case, I wish I new more about Goliath. If it's running under PLAY, then the only thing I can suggest is to keep Activity Monitor open and watch the numbers, taking special note of what those numbers are at the moment there's a problem.

If PLAY is crashing, check those crash reports to see what processes are at issue. It could just be that Goliath is overdue for an update but the release of SO-PLAY may have simply run EW a little more ragged than they expected.

[tyronehowe]

Blimey, Frodo, you always give such comprehensive answers! What would this forum be without you?!

More accurately, as you near 3GB add more instances and then *try* switching over to non-streaming if performance feels unstable. Even more accurately, if your machine has less than 4GB then your host will be cut short of its *designed* limit. As a result, PLAY will be working under a handicap where it's looking to access more RAM which just isn't available. That's why I wanted to stress that the threshold was 3GB --or-- 75% of your physical RAM ***whichever is smaller***.

Ok – I can certainly understand that. If a machine has only 4 GB of RAM, the 64-bit benefit of PLAY is neutralised because there IS no extra RAM for it to use. Whether the majority of 4Gb is used by PLAY or DP makes no difference, there is only 4Gb anyway.

It's because of PLAY's method of memory addressing which is along the same lines as VSL's. This is very new interim technology that deals with the gray area of RAM limits that bring our machines to their needs and keep certain kinds of resource-needy software from running effectively. We've been watching full tilt 64-bit apps "not arriving". Necessity is the mother of all invention. Hence, we're seeing this multi 32 coding instead of honest 64-bit because most major DAWs are still 32-bit.

Yup – I see that too. In fact, for quite a few years I’ve seen apps overcome the 32-bit addressing limit by simply running multiple processes that can EACH access 4Gb (although maybe 2.5Gb - 3Gb in practice, under Windows it would be either 1.6Gb or 2.6Gb). As you have said, VSL works this way – so does the Plogue Bidule host that I’ve seen used.

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?

With PLAY the first 3GB or so appear to operate within the host. Subsequent *plugin* instances somehow are handled by this "ousiao" server, allowing for all the convenience of running a standalone instance except as a plugin. The one downsides to running standalone is that you can (generally) only run one instance and not all standalones support rewire.

On the VSL side, there is an independent server running, but VSL has figured out how not to use very much of the host's memory at all.

I have experienced that as well (we have spoken about this before on a different thread). The “filling up my DP 3Gb before it uses the ousiao server” practice seems very odd. 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.

I need to perform some more tests when I get a moment – I need to test in Logic as well just to check.

They've given options to suit different users. To stream or not to stream. That is the question. Whether it is nobler in the mind to suffer the slings and arrows of calling tech support in the face of their outrageous fortune... yadda-yadda

Depending upon how much RAM you have, non-streaming may simply work better

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?

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).

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’m not asking Frodo these questions,

woopsie...

ah well maybe I guessed that you might just answer anyway because you are such a good sport about all this.

Quirky, or simply "peculiar", the latter being perhaps less bad and more akin to "different". Few companies tell you all the "why's". They're pretty good at telling you what you *can* do, but good luck with gleaning the "how's".

PLAY's method seems a little more old-school in that its Settings and Prefs bear more in common with Kontakt, among other VIs. VSL doesn't offer users engine customization options. Memory addressing is much more self-governing. If VSL needs more memory it seems to know on its own how to go about parsing that memory. PLAY will get to a point and then tell you that it couldn't do what you wanted because of the way the prefs are set. Somehow, the user has to figure out what it is that PLAY needs.

I've not figured out which method I prefer.

Peculiar does sound better than quirky, you’re right. 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.

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.

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.

.. but the more we post and test, the more everyone can benefit.

[Frodo]

Blimey, Frodo, you always give such comprehensive answers! What would this forum be without you?!

A lot quieter?

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.

...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.

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.

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.

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.

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.

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.

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!

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.

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.

.. 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!

[obmit]

I too have problems with Play crashing DP when you edit CC's. I tried it again last night and it does it still in 5.13 and in DP6. When I emailed them they said they can not replicate the problem on 3 systems. My system is a Mac pro 8 core with 10 gigs of ram so power should not be an issue.

There is also the other issue with play and DP where it causes the arrow key to skip one option if you use it to go up or down a menu. They said this would be fixed in the last update, neither 79 or 80 have fixed it though and it is there in Dp6 as well.

I had to get through some recent projects that I had to use SD2 and MOR on so I did them in cubase. The vst version of play seems much stabler.

Obmit

[Frodo]

FWIW-- Play 1.0.083 was released with the past 48 hours. Also, EWQLSO 1.0.1 is also up.

Downloading now and will report back soon.

[haydnwalker]

Phew... Hard to keep up with you guys... i'll investigate all this
Where do you check this activity monitor. Is that in DP?

[tyronehowe]

Phew... Hard to keep up with you guys... i'll investigate all this
Where do you check this activity monitor. Is that in DP?

Hi

The Activity Monitor is part of OSX, you can find it in the Utilities folder within Applications. It’s worth dragging it to the Dock so you have easy access to it in the future.

[haydnwalker]

I've updated to PLAY with latest update 1.0.083 and have found it much more stable ... so far. if it continues this way then ...nice one East West! Fingers crossed. Anyone else?