Vienna Symphonic Library Forum
Forum Statistics

174,401 users have contributed to 41,834 threads and 252,997 posts.

In the past 24 hours, we have 2 new thread(s), 13 new post(s) and 65 new user(s).

  • VEP and PLAY

    I'm getting some random crashing of VEP. Was recording CC11 data on 3 midi tracks when it happened. Looks like a problem with PLAY. Problem signature Problem Event Name: BEX64 Application Name: Vienna Ensemble Pro x64.exe Application Version: 5.1.0.11548 Application Timestamp: 50534b11 Fault Module Name: play_VST_x64.dll Fault Module Version: 3.0.40.0 Fault Module Timestamp: 502aa2f8 Exception Offset: 00000000001d696f Exception Code: c000000d Exception Data: 0000000000000000 OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Additional Information 1: abb2 Additional Information 2: abb23192a1acf8bab854607d477229e8 Additional Information 3: 8e25 Additional Information 4: 8e259f656cfe76f561ec7a4d2c868d56 Extra information about the problem Bucket ID: 3303944616

  • I'm sorry, I have no solution, but I'm getting worried reading your post. Mac user here, planning on building a PC to host EW Play inside VEPro. I already use VEPro on my main machine/DAW, a Mac Pro running Pro Tools HDX. Is this combo buggy overall?
    Thanks,
    Hakan


  • No hardly. Had two crashes so far past month. Since we all know play sucks, perhaps these crashes would happen in any host, not just vep. The crashlog seems to indicate play as the culprit.

  • Great, thanks! Good luck with solving your problem. [Y]


  • Regarding the memory server in Play, with 32GB RAM, will I need a 7200 SATA or will a 5400 be good enough? (Guess not) [^o)]


  • Here we go again.Faulting Application Path: C:\Program Files\Vienna Ensemble Pro\Vienna Ensemble Pro x64.exe Problem signature Problem Event Name: BEX64 Application Name: Vienna Ensemble Pro x64.exe Application Version: 5.1.0.11548 Application Timestamp: 50534b11 Fault Module Name: play_VST_x64.dll Fault Module Version: 3.0.40.0 Fault Module Timestamp: 502aa2f8 Exception Offset: 00000000001d696f Exception Code: c000000d Exception Data: 0000000000000000 OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Additional Information 1: c89c Additional Information 2: c89c36c6beff87016eb6b2d31c344df2 Additional Information 3: 71ef Additional Information 4: 71eff8a09266975e61d3217ddb1efce3

  • Eh why not get the 7200 RPM. can you even buy 5200 RPM anymore? It might work but 7200 RPM is the standard.

  • I got an offer from the company that builds my PC. They suggested a SSD for the system and a Caviar Green drive (5400). Since I don't know how the Play engine works, I thought I'd ask if that was good enough. Now I've gotten the advice to put the samples on another SSD, so I guess Play isn't very efficient. On my Mac Pro I seldom hit the roof, using Vienna Instruments and Kontakt, all samples stored on 7200 rpm HDDs.


  • It has nothing to do with how efficient PLAY is, but instead its about how many samples you are trying to stream SIMULTANEOUSLY. I have 3 SSDs and they are not all what they are cracked up to be. It all depends on your specific needs. What libs are you running? I dont use the SSDs for anything except hollywood strings. I also got one for my OS so that it boots faster. Everything else is fine on a 7200 RPM drive. I cant comment on whether 5200 would be sufficient.

  • Until recently the rumor was VSL couldnt take advantage of SSDs and it ran identically for users with 7200 RPM drives. I know VSL recommends 7200 of course, but VSL is relatively less demanding than other libraries on the market and you might be fine with 5200. It all depends how much you run at the same time. At the very least, I'd spread it out across multiple drives, and then in that situation your 5200 wont get pushed to its limits.

  • Ok thanks, I'm gonna go for an extra SSD for some of the Hollywood Strings and EW Pianos. I'm also putting some of my VSL libs on this PC on a 7200 HDD. On Mac it's obvious that Play is less efficient than VIPro and Kontakt. As far as I know, all three engines reads partly from a buffer kept in RAM, so I guess with a large memory buffer, the performance has a lot to do with how well the software is written. That's why I thought that on the PC platform with at least 32 GB RAM, I could get away with a 5400...


  • as far as I know the memory buffer isn't modifiable with play instruments. You can however load the entire instrument into ram, but this is impractical because a patch that takes 1GB of ram to stream would cost 12GB if you loaded it entirely into RAM. Its something ridiculous like that. Although you can try, I wouldn't dare do a PLAY instrument on a 5400. I know VSL will at least work on a 5400 external drive, since I tried that once. Not going to guarantee that you can get many instruments running but i know it works.

  • Håkan,

    A while ago, I made a (theoretical) burst performance analysis of a couple of harddrives. I now added the Caviar Green as well. As you can see from the table, SSDs are clearly superior to regular drives. The Caviar Green doesn't stand up very well in this competition. Even though regular drives can stream a reasonable amount of voices when triggered sequentially (such as dragging your forearm on the piano), they are terrible at pure burst performance, triggering many notes at once. Quantized music would be the hardest task for a mechanical drive.

    Many new libraries, such as Dimension Strings or Hollywood Strings, trigger many voices (players, microphones etc) exactly at the same time. Then the burst values from this table are most important.


  • Thanks a lot Martin, very informative! Such a huge difference between mechanical and SSD! [:O] The Caviar eco-drive, on the other hand, is not far from the Caviar Black. Luckily, when doing orchestral stuff, I hardly quantize at all.


  • The 7200rpm drive is about 25% faster than the 5400rpm drive. 25 notes burst performance at 16384 (default) buffer size is not much however. One keypress of a Dimension strings patch with 8 violins and 4 layers velocity xfade gives 32 voices...


  • Martin, next time you do tests if would be useful to do some at much lower buffers. I've never gone as high as 1024. Mostly I work at 128 and bump it up to 512 for mixing, but it is the 128 that is most important, because that's as high as I want to go for playing live.

    DG


  • DG,

    the chart does not refer to soundcard buffers - they are precache buffers as set in VIPro directory manager.


  •  I think the values are no audio buffers, these are the preload buffer sizes you can setup in VI PRO.

    Default size is 16384, and I don't recomment to go below 2048. My usual buffer size working with SSDs is 4096 which enables me to load more than 1.000.000 samples into RAM on my system.

    best

    Herb

    edit: I see Martin was faster with his reply.


  • last edited
    last edited

    @MS said:

    DG,

    the chart does not refer to soundcard buffers - they are precache buffers as set in VIPro directory manager.

    Ah, I see. OK move along then. Nothing to see here. [;)]

    DG


  • last edited
    last edited

    @herb said:

     I think the values are no audio buffers, these are the preload buffer sizes you can setup in VI PRO.

    Default size is 16384, and I don't recomment to go below 2048. My usual buffer size working with SSDs is 4096 which enables me to load more than 1.000.000 samples into RAM on my system.

    best

    Herb

    edit: I see Martin was faster with his reply.

    Yeah, you need to up your "fast on the draw" skills, Herb.  [:D]

    DG