Omnisphere 2 slow interface

[zvenx]

Hmmm.. I beta test for a few companies (not spectrasonics) and in every case that I have had issues that were hard to reproduce, they logged on and watched me do it or give me logging tools to create logs to send to them, or give me a version that does keep debug logs, never have they installed their development software or builds on my computer....

There may be security risks involved, why they never have done that in my experience..

(and these are companies I have signed legal nda's with, that is I am legally inhibited from leaking their developer versions etc)
rsp

[Splidge]

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

My standalone Omnisphere doesn't appear to be doing any of that. If you have utilities running that are injecting into applications to provide special features then they could be doing those things within the Omnisphere/DAW processes.

[MegaPixel]

Hmmm.. I beta test for a few companies (not spectrasonics) and in every case that I have had issues that were hard to reproduce, they logged on and watched me do it or give me logging tools to create logs to send to them, or give me a version that does keep debug logs, never have they installed their development software or builds on my computer....

There may be security risks involved, why they never have done that in my experience..

(and these are companies I have signed legal nda's with, that is I am legally inhibited from leaking their developer versions etc)
rsp

True but I work with web software so for me it's remote in and check a live mirror set to debug mode for electron or web or mobile applications. But yes like you I am under NDA on every job. I created logging utilities for doing this remote many years ago but nothing quite beats direct access to the machine that has issue.

I would request that a customer that is willing to do this sign an NDA, but I would assume it would only be visual studio they would need to install and set omni to debug mode (support mentioned it often to me but never did put it in that mode). If spectrasonics are reading this, I'm happy to sign an NDA and let you loose on my PC, but this is a work PC so no wandering our client files...

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

My standalone Omnisphere doesn't appear to be doing any of that. If you have utilities running that are injecting into applications to provide special features then they could be doing those things within the Omnisphere/DAW processes.

The exe for me was going through more than the dll/vst3 (Stardock Fences etc), all 3 (exe, dll and vst) were accessing powershell etc...

I don't have utilities which hook on any system process's installed unless I run them intentionally, but I have Apache, Mongo, MySQL, Docker, xampp, VisualStudio, VSCode etc, Adobe Creative Suite etc and various small utility tools installed, some add services which I have all set to manual startup etc. Most of the tools I build are in node/py/php and are run from the command line and don't reside in memory or services, but nothing that has interfered with any other software. Used to have issues with skype many years ago when I had it installed conflicting on usage of localhost:8080/127.0.0.1:8080 etc.

I'm very fussy with windows startup programs and auto run services, right through to anything that puts entries into the system right click menu and registry. I will delete/stop/etc them after install to keep things fast.

Also tried both gaming and productivity versions of the NVIDIA driver, but I use the productivity one with NVSLIMER which strips out even more bloat from NVIDIA (including it's telemetry).

But I do a system format every couple of months and it's always the same, but next format I will install bitwig and then omni before even windows updates and see if it acts up, if it doesn't then I will test it after each software install to see which one causes the problem... If any, god... that's going to make things a take a lot longer... Oh the joy...


My main tools:

main-tools.png

[MegaPixel]

Well here's a turn of events...
I fired up Visual Studio, ran the profiles / debugger on the exe and guess what... Apart from the extremely slow loading time, Omni was running fine, a bit of lag but usable...

So shut down everything, fired up my DAW, loaded up Omni, waited 3 weeks for it to load and tested it... Slow and clumsy as expected. Then attached visual studio debug/profiler to the bitwig process, a memory address break point fired when I changed from 1 patch to another patch in omni but then it was working great...

So to make sure this wasn't a fluke, closed VS and my DAW, re-started my DAW and loaded up omni, apart from the 3 week start up time it was working fine.... Not lag free but usable... But even more oddly didn't require the VisualStudio trick to get it to work normally again... Now usable in BitWig 4, StudioOne 5 & FLStudio 20

That's just... WTF...

[noiseboyuk]

I don't know what any of that means MegaPixel, but can you go back to Spectrasonics support with the info? Gotta help them...

[exmatproton]

I don't know what any of that means MegaPixel, but can you go back to Spectrasonics support with the info? Gotta help them...

+1 on this indeed. 3 fps while dragging an envelope point is just crazy... .. . (vst 2, vst 3, .exe, across all DAW's incl. fls, reaper, reason, ableton, bitwig)

[MegaPixel]

I don't know what any of that means MegaPixel, but can you go back to Spectrasonics support with the info? Gotta help them...

+1 on this indeed. 3 fps while dragging an envelope point is just crazy... .. . (vst 2, vst 3, .exe, across all DAW's incl. fls, reaper, reason, ableton, bitwig)

Try the following, it has made omni tolerable for me...
I will still probably sell it though...


1. Install VisualStudio Express (free)
https://visualstudio.microsoft.com/downloads/

2. Start omni exe and then start visualstudio

3. VisualStudio splash screen has a bunch of options and boxes (i'm using older version however, so your might be different, but somewhere there is "continue without code". Click that to just get into the program without creating a project.

4. Click Debug menu, select "Performance Profiler"

5. Click choose target, then select running process, find omnisphere and select it.

6. Tick the cpu usage and events viewer tick boxes then click start button.

7. Bring omnisphere back into view and start using it, switch presets etc. At some point it should freak VisualStudio out and VisualStudio will come back into view with some kind of issue, just ignore or press ok, and go back to omnisphere and now see if it's working faster. This is where mine started working a lot faster but still like complete and utter shait compared to any VST I have. NOTE: If visual studio doesn't freak out not to worry, move on to next step.

8. Now close both VisualStudio and Omnisphere exe (standalone) and open your daw, create a blank project and just add omnisphere.

9. Do the above process but attach the profiler to the running process of your daw and then start to use omnisphere in your daw, hopefully this will cause visual studio to pick up the error. NOTE: There may be multiple instances of your daw process and some may not cause visual studio to pickup the error when using omnisphere. The error detection by VisualStudio is what caused Omnisphere to screw itself up and break something, probably visualstudio stopped it writing to a file and damaged it in some way so omni now no longer uses it or part of its database files or something. If you don't get the error try all the process mentioning your daw and then if omnisphere is listed then them also. Just make sure you go and use omnisphere once you start the profiler to try and get it to cause visual studio to detect it doing stupid things...


Support wont fix this they just take you through usual steps of turn of AV, make sure your using your graphics card etc... It's basically 200 year old programming, single core and dragging the preset bar up and down fast can take 1 of my i9900k cores to 60% to 70% cpu load... It's just old programming, they done the bare minimum to update it and keep it going, old concepts on how to load and stream assets and use cpu cores, old ideas on how to index data files and database assets etc... But it does have some nice sounding patches, but it's very over hyped. IMO (each to their own opp').

Hope that improves omni for you, like it has for me.

[exmatproton]

The error detection by VisualStudio is what caused Omnisphere to screw itself up and break something, probably visualstudio stopped it writing to a file and damaged it in some way so omni now no longer uses it or part of its database files or something. If you don't get the error try all the process mentioning your daw and then if omnisphere is listed then them also. Just make sure you go and use omnisphere once you start the profiler to try and get it to cause visual studio to detect it doing stupid things...

Yeah..no. Tried the profiler (literally all steps) but without success..
CPU usage seems fine. However, the UI is just so freaking slow. Running between 3 and 20 FPS when dragging an envelope node.

Browsing presets and samples aren't the real issue. I can live with the speed Omni handles that.

btw..thnx for the detailed description

[noiseboyuk]

This has been going on for years and still I don't think any of us have isolated it. In standalone mode, Omni is a dream. I've tried VST2 and VST3 in Cubase (currently v12.0.30) and it's very slow on a project which opens with 2 instances. With one instance, much quicker, but then I add a second and... well, now it's still quick. Huh?

Stylus can be even worse - sometimes it can be 4 or 5 seconds to just change a patch in Cubase (1 instance, 1x magnification). I just can't replicate any problem consistently though.

In general its well behaved right after an update, but then the problems start. But they're always ok in standalone.

ALL VERY FRUSTRATING.

[MegaPixel]

This has been going on for years and still I don't think any of us have isolated it. In standalone mode, Omni is a dream. I've tried VST2 and VST3 in Cubase (currently v12.0.30) and it's very slow on a project which opens with 2 instances. With one instance, much quicker, but then I add a second and... well, now it's still quick. Huh?

Stylus can be even worse - sometimes it can be 4 or 5 seconds to just change a patch in Cubase (1 instance, 1x magnification). I just can't replicate any problem consistently though.

In general its well behaved right after an update, but then the problems start. But they're always ok in standalone.

ALL VERY FRUSTRATING.

All I can suggest is for each instance of omni you have is to bounce it down to a sample then disable the track and all plugins on it, and move on.

I think it's end of days for omni till they do a ground up rebuild (3.0) for modern hardware and a far better asset streaming/loading and storage mechanism...

A mysqlite db (free tech) can easily store 100,000+ patches and if used correctly wouldn't slow anything down. Eg done right see Serum, Eg done wrong NI's massive (add a folder with about 1000 patches to its folder preferences to scan, it will never stop loading)... Omni's implementation of this is FUBAR, I've never seen anything like it, even as a programmer I can't work out the reasoning behind their file system and data storage.

There's a lot of old code out there and much of it is not written well...
These guy n gals are using c++ which is about as powerful as it gets, unless you go to assembly code, and somehow they still manage to write programs which are slower than Web programming languages (GUI/DB data, not audio processing)...

I'm tempted to start up a patreon to raise money to build an instrument that would cover everything omni, phaseplant, rapid, avenger, halion 6, Falcon and kontakt can do (and more) but in a modular (only limit is your hardware) node design kind of way and keep it easy to use. I would drop my day job to work on it and hire 2 c++ vst devs (pc & mac) if I could get the funding... No harm in dreaming eh...

[noiseboyuk]

Interesting, MegaPixel, but if it works ok in standalone it - surely - it should be able to work ok as a VST without a ground-up rewrite.

(I don’t really use it in PT, but I’m gonna do some AAX tests tomorrow if I remember).

[MegaPixel]

Interesting, MegaPixel, but if it works ok in standalone it - surely - it should be able to work ok as a VST without a ground-up rewrite.

(I don’t really use it in PT, but I’m gonna do some AAX tests tomorrow if I remember).

The standalone version would have access to lower level processes directly and not be sandboxed in a DAW which would grant it more capabilities/power. Technically every standalone version of any VST/AXX/AU/etc should have way more capabilities and resource available to it. Not to mention the DAW wouldn't be running which would also free up cpu and ram there.

An idea just popped in my head, I was looking into Audio Modeling today and they use something called "Divisimate" to assist with spreading notes out across channels. It might (big might) be possible to use Divisimate to pick up midi from multiple instances of Omni in standalone mode in the daw via "Divisimate".

[noiseboyuk]

Divisimate scares me. And it’s really inconvenient to have to load things not in the project.

I might play around with it in VE Pro tomorrow as well. That’s also a little inconvenient, but at least there’s a mode when you save it in the project. I don’t think I’d work with it like that IRL, but for diagnostics it’ll be interesting.

[MegaPixel]

Divisimate scares me. And it’s really inconvenient to have to load things not in the project.

I might play around with it in VE Pro tomorrow as well. That’s also a little inconvenient, but at least there’s a mode when you save it in the project. I don’t think I’d work with it like that IRL, but for diagnostics it’ll be interesting.

There's also Unify, which can load omni into it, some have had luck with omni working much better being loaded from that inside the daw or via unify standalone. For me, no such luck...

[noiseboyuk]

Let the testing begin.

Blank Cubase project. Create a new Stylus RMX track - performs perfectly. Get rid, start again this time with a new Omnisphere track - performs perfectly. Add a 2nd. Performs perfectly.

Next I picked the busy recent project where everything was at a crawl. I opened Resource Manager to see what was going on. Clicking around the Omni browser certainly makes the CPU on Core 3 jump, but now it is still performing ok even on a busy project.



Stylus, on the other hand, slows to it's 4-5s crawl to load a patch, even though the CPU plots look superficially similar:



I now think to open XO, which I know slows the meters of Cubase down when the GUI is open. And no wonder, it causes core 3 to hit 100% permanently even at idle. Now I click around the Omni browser, and... it STILL performs perfectly:



So.. what the hell?

Perhaps this shouldn't be a surprise. Were it something this simple, the issue would have been identified by now. Reports have come in from multiple DAWs so it is not specific to Cubase, and I'm now thinking it is highly unlikely to be to do with the VST versions.

Here's what we can say with confidence - clicking the Spectrasonics browsers draws heavily on the CPU. However, this may or may not correlate with poor browser performance, and no-one has yet found a reliable way to replicate the fault.

(side note - jeepers, XO. It remains at 100% CPU all the the time the GUI is open. It drops to 30% when it is closed).