Omnisphere 2 slow interface

[MegaPixel]

AMD 5900X 64gb RAM, RX 580 8gb GFX , 2TB NVme with the bulk of Omnisphere on a internal 1TB SSD

Works perfectly here.

Which one are you loading the VST3 or VST2 version ?

Tried both, was on screen share with support for more than 2 hours, no joy...

[LeVzi]

AMD 5900X 64gb RAM, RX 580 8gb GFX , 2TB NVme with the bulk of Omnisphere on a internal 1TB SSD

Works perfectly here.

Which one are you loading the VST3 or VST2 version ?

Tried both, was on screen share with support for more than 2 hours, no joy...

You are using onboard graphics ? Have you optimized that ?

[MegaPixel]

You are using onboard graphics ? Have you optimized that ?

It was a couple of months ago that I was on screen share with the support guy from omni for 2+ hours, I remember something about selecting NVIDIA driver... But onboard graphics is not enabled or plugged in, the RTX 3080 is. But if memory serves me correctly we did this basically of which it was already set to NVIDIA.
https://www.spectrasonics.net/support/k ... egoryID=20

Old videos I sent them (yes latest updates have been applied since they came out):

Video: Load speed, bank scroll (see mouse wheel scroll top right symbols), non responsive and then crash



Video: Omni lagging out, cpu core utilisation, daw lag transference (which is impressive seeing that Bitwig sandboxes it - also tried not standboxing it)



Video: Lagging out on preset browser, lay being passed onto the daw, single threaded programming shown using cpu core 3 aka id 2. Its worse than this now, I have several banks installed which has made it worse... The self jumping preset browser... Lag passed into DAW etc...



Unify loads Omni up at an impressive speed compared to Bitwig 4, Studio One 5 and FLStudio 20 however...

Blender has no problems...
Adobe Creative Suite have no problems...
Program tools have no problems with compile times, far more taxing on NVME and SSD I/O than Omnisphere would ever be... Single threaded some tools and some which use all cores...

It's just Omni, but it could be some software interfering with it... Of which I have fully disabled windows defender (which was not in use anyway) and bitdefender uninstalled. Even added exceptions to omni on local nvme and on ssd (both internal lol), even enabled and disabled same result.

I need to see the program running in the profiler in VisualStudio or something to do their job...

[LeVzi]

None of that makes any sense. Although that single core running high suggests something is going wrong.

tbh nothing I could suggest would help because the people who made Omni have looked.

What about Omni's standalone ? That working OK ?

[MegaPixel]

What about Omni's standalone ? That working OK ?

Nope, same, it is a bit better but not by much...

[zvenx]

Only thing I noticed in your video is your sample buffer size seems a strange number (360), I usually see it as multiples of 16 (16,32,64,128,256,512 etc)
rsp

[MegaPixel]

Only thing I noticed in your video is your sample buffer size seems a strange number (360), I usually see it as multiples of 16 (16,32,64,128,256,512 etc)
rsp

Ye, me and support were changing it to see if it would help, even tried windows WAZABI (WASAPI) audio... But as we are not using the GPU for audio and not dealing with texture buffers then not sure settings of multiples of 16 are relevant that much but I do tend to either go for 256 or 512 out habit.

I need one of the actual devs to remote in, install a version of omni that is a development build and run the visual studio profiler (or use their own tools) on the program to see what is actually causing it to lock up.

When I do preset clean ups, I create omni banks to import, now that takes a very very very long time, like go make a cup of tea kind of time (same for the import) and then once it has created the *.omnisphere file it locks up then x10 the time it took to create the .omni file, which I usually just crash it or I would be waiting 10 to 20 mins for the DAW to become responsive again, luckily Bitwig doesn't crash when I do this thanks to sandboxing Omni (and yes, tried all of bitwigs options on sandboxing omni)...

[LeVzi]

Is it literally the only VST that does this to your system ?

[MegaPixel]

Is it literally the only VST that does this to your system ?

Yep, even cooked up a stress test of around 40+, comprising of a few instances of Falcon x 10, Halion 6 x 4, Diva x 1, Kontakt x 10, Phaseplant x 4, Serum x 3, Massive, Massive X etc etc etc... All playing a chord sequence arped via bitwig (where applicable to certain presets in each vst), got the DSP to around 80%, without any lag issues at all, no crackles, everything was as responsive as if I just opened a clean project.

As soon as I add Omni, tried switching between one preset bank and another or one preset to another, "PLUGIN UNRESPONSIVE WARNING", wait wait wait wait, DSP crackle, wait wait wait, preset browser jumps around and finally select what I selected or sometimes jumps to a previous selection or scrolls straight to the top and then becomes responsive again...

But this happens if its just omni on it's own in a fresh new project...

I configured SYSMON to watch all of omni's files including my DAWs (exe, dll and vst3), nothing out of the norm. However omni does do a lot of looking at files which it shouldn't. But the events stop coming in as soon as it gets to a point (the lock up phase) and then it when it starts to work again the event logging resumes.

It's omni... I'm in no doubt about that...

[MegaPixel]

Is it literally the only VST that does this to your system ?

PS. Just cooked up a bit of an unrealistic stress test and done things fast to show you how it gets after a bit of usage, but doing things this fast gets it there quicker to show you.

NOTE: I have to use WASAPI audio for this (obs recording, I don't know how to record asio audio with it), so DSP load is higher, but that's even better for the stress test. But with this many VSTs active (muted doesn't affect cpu/dsp use) combined with WASAPI use, SOME of the other VSTs are not as responsive as they are to open as normal using asio but surprisingly Falcon, Halion 6 & Kontakt are like normal, Massive X & Zebra are slower to open, but not that bad, once open usage is like normal, but it's nothing compared to Omnisphere...

Also it was a good run for Omnisphere initially, it loaded a bit faster than usual for me, even though it was a long time in comparison, and the window actually opened quicker, then it soon all falls apart...

I didn't wait long enough for BitWig to give the Unresponsive Plugin Notice and just killed it myself... But if I left it for about 10 to 15 minutes at the end of the video it would become responsive again.

I am curating all my expansions and then all of spectrasonics presets (not looking forward to that) to my own omnibanks and then going to delete everything and import only what I curated, to try and lighten the load on Lagsphere and see if it performs as expected.

[LeVzi]

Well, that's definitely one for the dev's, thats bizarre tbh, really no clue why that happens. I hope they sort it.

[Splidge]

But this happens if its just omni on it's own in a fresh new project...

Out of interest, do you get the same behaviour in Ableton Live? I've used the Visual Studio 2019 debugger and profiling tools on the Live executable before to diagnose performance problems in plugins (e.g. AuroraFM's window dragging lag, which turned out to be due to excessive mouse event reporting and not the plugin's fault).

One thing I noticed about Omnisphere is the staggering quantity of mutex handles - about 36,000 - each instance creates according to the count in Task Manager and sysinternals/Handle. It doesn't seem too concerned about using resources efficiently.

[MegaPixel]

Well, that's definitely one for the dev's, thats bizarre tbh, really no clue why that happens. I hope they sort it.

It's been at least 5 months, no word from Spectrasonics, support was great initially but there have been no fixes or communication there after...

But this happens if its just omni on it's own in a fresh new project...

Out of interest, do you get the same behaviour in Ableton Live? I've used the Visual Studio 2019 debugger and profiling tools on the Live executable before to diagnose performance problems in plugins (e.g. AuroraFM's window dragging lag, which turned out to be due to excessive mouse event reporting and not the plugin's fault).

One thing I noticed about Omnisphere is the staggering quantity of mutex handles - about 36,000 - each instance creates according to the count in Task Manager and sysinternals/Handle. It doesn't seem too concerned about using resources efficiently.

RE: Other DAWs
I only have Bitwig (My DAW of choice), Studio One and FLStudio, same result. But this happens in stand alone mode also (but even if it was fine in standalone mode, it would be no of use to me not in a DAW).

RE: Debugging
Yeah, I was watching it in SYSMON, it was using powershell a number of times?, all over the place in windows folders, even got into my Stardock Fences for some reason... Now what has my desktop got to do with the thing... Watching it call home and what data it was sending... It's just old, very old, and the code has probably become an unmanageable behemoth of spaghetti, which their developers are probably calling it a turd wrapped in glitter and are just hot patching in any way possible to get it to do new things and to keep it working... It appears to be single threaded, but judging by it's age, that's fair enough but soo many other VSTs are also with little problem.


Well... I will keep exporting omni files slowly till I got everything I think I could use or kinda like out of it and wipe it clean of core presets and purchased banks etc and import them, it might give it new life... But that's going to take time, will do a bit every weekend over a few months...

If not keep an eye on KVR for Omni for sale lol

[zvenx]

I have seen this one over the years by a few posters indeed...probably since omnisphere 1..
Like I mentioned, Spectrasonics hasn't been able to replicate it afaik, which is the reason why there has been no fix afaik.

rsp

[MegaPixel]

I have seen this one over the years by a few posters indeed...probably since omnisphere 1..
Like I mentioned, Spectrasonics hasn't been able to replicate it afaik, which is the reason why there has been no fix afaik.

rsp

All they need to do is get just 1 (of which there are many I've found with the same issue), to allow them to remote in to their machine, install some of their development software and the development build of omni and check it out... I would be happy to let them loose...

Something I have done many times with my own clients and for agencies I've worked for over the years.