Omnisphere and memory?

[kdm]

I'm working on an trailer score and had Kontakt 3, Omnisphere, RMX and Play (SD2) loaded - only a couple of instruments in the last three. Memory was fine until I started swapping out a couple of instruments in Omni, then it apparently dropped to about 500k free. Of course Nuendo crashed. I could reopen the project, but lost Decklink access (just too little memory - driver was fine) - Nuendo warned it was switching to onscreen display (never seen that error message before).

I removed all 3 instances of Kontakt, which was about 70% of the sample loading, saved the project, closed Nuendo and reopened it - same memory - around 500k free (maybe 200, can't recall exactly). So I removed all but one instrument from Play and RMX, trying to cut back to the bare minimum instruments I was working on at the time - same memory usage after saving/reopening.

This time I removed Omnisphere completely, saved, closed, etc. Now memory was back up to over 2G free. Omni only had a synth bass - mostly synthesis instead of samples. It seems Omni can freak out and swallow up a massive amount of memory under some conditions. I know the 2 instruments I had loaded in it shouldn't consume close to 2G of ram, but apparently it had locked out free memory from other instruments/Nuendo. Just a guess, but a weird one.

Since I bought Omni not long after it came out, I have yet to have a serious project with it (i.e. one with more than just an instance of Omni alone), run smoothly. Pretty expensive to have to dedicate a slave PC to it, but it looks like the only way to run Omni along with other VSTis.

Anyone had weird memory problems with Omni in Nuendo/Cubase?

[Sam]

Yep, pretty much just like you say it happens. It can all go pearshaped really quick. Pity it sounds so damn fantastic :(

[kdm]

Yep, pretty much just like you say it happens. It can all go pearshaped really quick. Pity it sounds so damn fantastic :(

I guess this will be an ongoing problem for a while - I've had issues with Omni since day 1, esp. playing nice with other sample-players. (Kontakt and Play are fine together).

Let me know if you find a repro since that's the only way this will get addressed. I'll post here if I find one as well.

[Animus]

Pretty much the same story with all the samplelib developers turned software developers. Their software is bloated buggy crap.

[Sam]

I know atmosphere was a lot less than omni is, but by god it was one stable son
of a bitch here. I had sessions with 8 or so going no sweat along side a huge Uad and native pluton compliment and reason rewired etc etc

[Animus]

Atmosphere was a third party engine I think. Ominsphere/Trillian are built in house.

[kdm]

Omni is an amazing synth, and to some degree worth putting up with some of the headaches (it does work fine most of the time, though when it doesn't I end up not using it at all); but this trend of companies developing their own engines/players/etc does lead to quite a bit of reinventing the wheel of efficient, stable coding.

[TAFKAT]

Hey Dedric,

I have had numrous clients with Omnisphere all bitching about how unrealistically hungry it is compared to the Atmosphere that they had been using previously. Some could run 8-10 instances of Atmosphere without issue with other VSTi's, etc , no problem, but a few instruments loaded into Omni would tank the systems. The only solution was to go to 64 Bit O.S's for these clients , and numerous bridging options. That doesn't excuse or resolve the memory leak issues you reported tho , juts give some room to move before it goes belly up.

I agree that this trend of the companies developing their own dedicated engines isn't necessarily a better option when the engines are so inefficient and unstable , PLAY is another example. Its a 2 edged sword, they are probably feeling limited at being tied to a 3rd parties development timeline , so they step up and take control , but then go backwards in regards to stability , so their end users inevitabley are the ones who become the guinea pigs as they iron out the bugs. The other thing that gets my goat is the unrealistic memory footprints on some of these 32 bit VI's, BFD 2 is a perfect example, it is basically useless in a 32 bit system.

I digress..,

Yeh Omnisphere love the sound.., lets hope they sort the memory issues.. :-)

[kdm]

For anyone who has seen this - do you happen to have either or both of the following?:

1 - One or more instances of Kontakt? If so, where in the VSTi rack - before or after Omnisphere?

2 - The /3G switch enabled on a 32-bit system.

Here's my hypothesis - once free mem drops below 1.2G, with the /3G switch, that's where Omnisphere becomes unstable. Normally, Omni will report "out of memory" and start dropping samples, or simply crash the system (perhaps causing a memory leak). I've actually seen RMX report "out of memory" when it was the first VSTi in the project, and no memory used other than Nuendo's normal footprint - I think that's related to the /3G switch and how memory is mapped outside of the range Omni/RMX expect (does that sound possible Vin, or am I misinterpreting the effect of the /3G switch?).

Another side-effect could be Omni simply shutting off ASIO. That was a rather predictable bug earlier on pre 1.04 I think, but was fixed - it still seems to happen on rare occasions (like just now for me), when memory has dropped below 1.2G free.

Kontakt and Play don't seem to have problems with the /3G switch. I know some VST plugins can run into problems with memory below 1.2G (I've seen it with Voxengo plugins causing "serious errors"). Omni does however. And it doesn't manage it elegantly. Omni really needs its' own 64-bit slave, but that's a rather costly workaround.

[leggy]

Probably not a very popular thing to say around here but it works really well with OS X on my machine. Actually that's of no use to you at all is it? I'll get my coat.......


Good luck with it,

Rob

[kdm]

Probably not a very popular thing to say around here but it works really well with OS X on my machine. Actually that's of no use to you at all is it? I'll get my coat.......


Good luck with it,

Rob

Alone, or with other VSTi's? Unfortunately moving to a Mac is about 8x more expensive of a workaround than dedicating a slave to Omni. Currently I just have to watch ram usage, and try to work with Omni alone when I need more than a handful of instruments. No doubt a Win7 system with 16G+ of ram would probably solve it as well.

[Sam]

Probably not a very popular thing to say around here but it works really well with OS X on my machine. Actually that's of no use to you at all is it? I'll get my coat.......


Good luck with it,

Rob

actually that is of use to me rob! It kinda points to memory again, as the mem handling even in Leo is more forgiving than in xp32...
I think I has better open these problem projects up on my Leo boot and see if I can get the crashes and corruptions to happen under osx too...

[zvenx]

as much as a spectrasonics fanboy as I am, this pretty much is my experience too......and Glenn and Eric keep saying the solution is to go 64bit..so I dont' think these problems will ever be fixed sadly.
rsp

[kdm]

as much as a spectrasonics fanboy as I am, this pretty much is my experience too......and Glenn and Eric keep saying the solution is to go 64bit..so I dont' think these problems will ever be fixed sadly.
rsp

That's pretty much what I expect when I report this. I doubt they will take any interest in fixing 32-bit memory usage - the /3G switch approach isn't standard, so it's an easy out for developers if it causes problems. Doesn't make me a happy customer to have to dedicate yet another system just to circumvent lazy programming.

[TAFKAT]

But Omnisphere isn't 64 bit native, so if the guys from Spectrasonics are serious about recommending 64 BIT O.S's , then they should develop a native 64 bit version.

I'm with Dedric, I find it unacceptable that they are not interested in dealing with 32 bit memory issues, but only have a 32 bit plugin.. !

[leggy]

I thought that with the latest version Omnisphere is 64bit native? And then they have the memory server feature with 32bit usage that lets you access additional memory like Kontakt 4 does? Actually another solution to the might be to host it in VEP and then you can either run the 64 bit version or multiple 32 bit versions using as much memory as you have available.

http://www.spectrasonics.net/news/2010/namm-2010-full-cross-platform-64-bit-support-for-spectrasonics/

[TAFKAT]

Doh...,

I stand corrected.. :icon_redface:

I did check the main feature /spec page on their website before I posted, and they didn't mention anything about 64 Bit.., I'll slink away quietly now..:sulkoff:

[leggy]

Lol :)

[kdm]

Either way, 64-bit isn't a solution to bugs - it's an expensive transition for many of us that still have 32-bit versions of peripheral apps and plugins to upgrade (assuming there are 64-bit versions). I'm going to contact Spectrasonics today. I'm pretty sure what the problem is (/3G switch and 1.2G boundary, and conficts with how NI handles it), but I'm also pretty sure what the response will be....

Leggy, the memory server is only on OSX to circumvent the lack of true 64-bit DAW (Logic) support there.

[Vinark]

I think Jbridging Omnisphere should fix it. Creates it's own memory space.

Jbridging Kontakt and Omnisphere without the 3gb switch might even be more stable. Every Jbridged plugin has his own 3gb address space. Here the 3gb switch was always a bit flaky. I would never know when reloading large project could end up crashing because some stupid plug that didn't like being in the higher memory addresses suddenly got loaded there and crash the whole thing.

BTW I'm running XP64, C4 32 with all plugins 32 bit except Kontakt and Spectrasonics which I Jbridge to 64 bit. Like this I will never need to go fully 64 bit cause those memory hungry plugins are the only ones that need it. C4 can now use over 3gb which is plenty for all remaining plugs and synths.
I even bridge Reaktor 32 bit to get rid of the stupid Reaktor bug that resets the priority of cubase to normal.
Vincent