Hi folks,
 
I am working on a piece that has multiple synths involved, including a couple of instances of Hollywood Brass. For some reason, when I try to freeze these tracks, the resulting wave file is faulty -- the legato horn cuts out after every note rather than sustain, and it basically useless. I recall this problem in the past (or something similar, possibly bouncing Play instruments was acting dodgy?). But I also recall that it was fixed, either in Sonar or in Play. Is freezing Play tracks an issue for anyone else, at the moment?
 
Rob

It was a problem for me until I set Play to stream from memory/ram and not disk.

I've also had glitchy results with freezing Play. So I usually real-time record Play tracks using my RME's loop back function. As an alternative, you can use Sonar's Patch Point function to record your synth (Play) tracks. Also try unchecking the quick freeze box in freeze options and see if that helps. Frustratingly slow this way, but you should get what you hear. ASIO buffer size seems to be a factor too. Haven't tried gustabo's solution, but that will effect overall performance and have other consequences? Somewhere I read that EastWest recommends loading Play instances in Synth Rack ahead of other soft synths. So I usually start a project with multiple instances of Play loaded and load others (Kontakt, etc.) later. I wish there was a way to reorder synths in the rack to see if that improves performance. Feature request? Good luck, hope this helps.

I am having the same problem with Play when I try to bounce tracks, too. I had this problem before, it seemed fixed for a time, and now its back. I turned off Stream From Disk, and it solved the bounce and freeze problem, but now I find Play actually clicks and glitches out -- even when I set the buffer to ridiculously high levels. This is a major issue for me, as I do orchestral stuff, and the Hollywood libraries are a big part of my repertoire. It is kind odd that this just seems to have cropped up from nowhere. I am currently working on a bigger project than usual -- with multiple instances of Kontakt and Play, and I wonder if that is part of it...

Bigger projects consume more resources and overhead. How much RAM do you have? What are your system specs? Win 10 pro? Creator's update? Samples on fast drive, preferably SSD? I do mostly orchestral projects as well, and I'm finding Play and Kontakt don't always play nice together. My DAW with 64GB works great until I hit it too hard. CPU never goes over 20% but sometimes clicks and glitches appear out of nowhere if I cross an unseen line. When that happens, I bounce/freeze tracks and/or increase ASIO buffer to 1024, and usually that does the trick. I have projects with ~100 tracks and 8 instances of Play that run fine at 256 buffer or lower. When I add other non-Play synths, things can get buggy. Make sure to turn off WIFI - that's guaranteed to cause problems.

Well, all my specs are in my signature, except hard drives -- I have 5 drives, three SSDs and two WD Blacks, and most of my samples are on the SSDs, including all the Play stuff. I don't use Wifi, as I much prefer wired LAN connections for speed and stability, and ran network cable throughout my house for that reason. I closed what I was working on, and pulled up a much smaller project with only two instances of Play, 6 tracks and no other synths -- hardly a beast from a resource perspective -- and Play would not bounce nicely there, either. I suspect that this is a problem with Play and Sonar, rather than just a matter of resource management.
 
I should probably clarify that my current project is bigger than other things I have been working on lately. I have had projects this big in the past, but I don't recall any issues with Play (aside from a brief period last year, I think, where Play wasn't bouncing properly, and which was addressed in a patch - at least, I seem to recall?). Now all of a sudden I can't get Play to behave nicely, and while there are work arounds, they are kind of a pain to use.

Starting with Play 5 they changed how it works with streaming samples resulting in issues when doing final rendering (more so on Windows I think than Mac which may explain why they haven't fixed it).  5.04 actually seems worse.  Unless your libraries are on a fast SSD drive, no bounce down/final render will be correct.  Release tails on patches won't render reliably.  As well as other missing bits.  And even with an SSD drive I think results are suspect. 
 
This happens in Reaper and SONAR, it's not a SONAR issue.  I have a two MIDI track project using two string patches that fails in both Reaper and SONAR.  Doesn't require some "super" complex project to have a problem. 
 
If you select every loaded instrument in Play and turn off streaming from disc before doing the export/freeze you will get the correct results (though the memory usage will be very high).  Or (if possible) you can go back to Play 4.3.5. But you loose new features added to Play 5.
 

I would think that if it plays back OK it should render in real time, too. Have you tried setting the slow bounce option? That inserts the usual wait times during the bounce that don't happen during a normal fast bounce, allowing the disk to keep up. Just un-check the "Fast bounce" box at the top of the freeze options.

Fast vs slow bounce does produce different results but not "correct" results.  EastWest release notes on Play have noted a number of issues with final renders vs realtime play, but while they keep tweaking it, they still haven't fixed it.  They are certainly doing something different when rendering vs realtime playback, but both render types have issues with getting sample content to the audio engine.  I think I only notice it more because most of my EastWest libraries are on a NAS network drive.  So the missing bits shows up much more than when the libraries are on a fast SSD.
 
I should also note that it fails during normal playback too, but it's much harder to notice, since Window's file caching generally covers up the failures.  So you re-play a section and it sounds right because Windows has cached all the file data necessary.  You think it's good/was just a glitch and move on.  But the truth is the engine did fail and will fail again, under the right conditions.
 

I tried slow bounce, and it was better but not perfect. And while it will render in full when I disable stream from disk, the resulting audio is has artifacts in it. Using patch-points to record the solo'd track to an audio track works, and that's what I have been doing, but its a hassle. 
 
Oddly, rendering Play does work for me in Reaper. I tried that last night, and I had no problem with it. Mind you, it was only a test with 4 tracks and a couple of Play instances, so that may not be reflective of how a full project would behave.