Hi Everyone,

I'm having an issue with Omnisphere that I never used to have... Basically some of the patches are hot/crackling/staticky. They're not in the red at all... It's not like mixing them down helps. It's like IN the patch. BUT, if I play that patch by itself, it sounds fine. It's only when a full song of multiple tracks is going does the issue start to happen. Once it does, its totally predictable. The crackling noises happen in the same spots every time I play the song.

Also, I've found that panning that particular track with an effected Omnisphere patch in it to the left or right makes the problem much worse. The crackling gets louder.

I'm pretty sure it's not an issue of resources... I mean my songs have been getting bigger than they ever were in the past, but I'm pretty sure I'm good as far as RAM and my Processor is concerned for projects of the size I'm working with.

Can anyone think of anything that could be causing this or any way to fix it? These songs are in the mixing down phase, so I'm fine with freezing the tracks, but even then the crackling seems to freeze along with them.
 
Could there be an option to play with in my Audio / Driver settings? 

Thank you for your help.

Omni is pretty demanding and anytime I had the symptoms you're reporting it was resource related.
 
You could try creating a new project with just Omni and copying the offending midi track into it, using the same omni patch you are using now. See if the issues still exist. Just a thought.

Your hard drive may be having a hard time keeping up, which would explain why the patch sounds OK in solo but crackles in context. Try increasing the preload memory size (click the System button).

Thank you both of you, I'm going to give these two suggestions a try and report back... Hopefully with some clean music haha.

An instance of Omnisphere can only run on a single core. Once you notice crackling in Omni patches, open a new instance of Omni and recreate a few patches in the new instance. This will allow Sonar to run the second instance on a different core.
 
There are other things you can do, like load "lite" versions of the patches, or use Global effects instead of per patch (or disable the FX in Omni altogether). However, to me, the FX are a large part of many patches, so I'd rather just create as many instances as I need.
 
Regards,
Dan
 

Good suggestion, Dan. Separate instances will also allow you to freeze instruments individually.
 
Here's what Spectrasonics has to say:
 

On single and dual-core systems, it's best to load multiple Parts (on different MIDI channels) within a single instance of Omnisphere, before opening any additional instances of the instrument. This is the best way to utilize the available CPU power for Omnisphere.

However, if a multi-core system is used, it can be beneficial to open multiple instances of Omnisphere to distribute the processor load between the cores. The resource handling is done by the host, so in this case it's useful to open more than one instance of Omnisphere. So the most efficient use on a multicore machine is to use a couple of instances multitimbrally - if assigning all Parts to a single instance is using up all the resources of a single core. Consult your host's documentation to make sure that it has support for multi-core/multi-processor systems.

 
However, the CPU benefit of multiple instances depends on whether or not the patches actually play concurrently. Because I typically use Omnisphere for color and accents rather than main instruments, I'll often have many patches in a single multi that aren't all playing at the same time. In that scenario, there is little benefit to multiple instances beyond separate freezing.
 

OK so a couple notes...
 
I found the setting to slide up the preload memory size... I'm not 100% if it's doing the job... Funny thing is on one song it seemed to be working (I'll know better once I go play it in my car... the crackle is much more apparent out there than on my monitors/headphones... but it does seem to be working). But on the next song I tried, it didn't seem to be making a difference...
 
SO, I went to the other suggestion of creating a new project and copying that single midi track over to it with a new instance of Omnisphere using the same patch. Now it did seem to save the higher preload memory size as a default in omnisphere, so we're working with that and a brand new sonar project... And comparing the two is night and day, it's totally clean in the new project, then I jump over and its crackly (even when soloed) in the other project.
 
SO, I tried another thing... I froze the track in the original project and it freezes with the crackling... No good... BUT then I froze the track in the new project and copied the frozen audio over, and that works great.
 
SO... We've got a serviceable, although annoying workaround. But, what is it exactly that's going on here? Is it a resources issue? I would have thought freezing the track in the original project would be good enough for resource related issues. According to the Sonar resources thing I'm using 57% of my system memory.
 
Also I tend to use just one patch/channel per Omnisphere instance. The song in question uses 9 instances, along with a bunch of other VSTs.
 
For now, I think that one track that I just fixed using the new project and freezing and copying the audio over method was the only track crackling in this particular project, so I'm gonna go finish it up. But if anyone has any further thoughts on this, I'd definitely appreciate it.  I'm hoping that maybe with the upped pre-load memory size, it'll at least be better for new projects going forward?
 
Thanks again for your help. Sorry, I know this is a long post haha.

Happy to hear you are, at least able, to find a temporary work around. Just curious what type of CPU and Drive you are using for your system.
 
9 instances of Omni could really be taxing both of those if they are all being used concurrently... 
 
If you already have a current multi core intel processor with a high clock speed and a fast sata III SSD I don't know what the solution might be running a heavy load other than putting in another sample drive to supply the non-Omni samples.
 
Might want to contact Spectrasonics support as they are usually pretty quick and helpful with issues.

My OS drive is a Samsung EVO SSD, and all the Omnisphere stuff is on a 2nd internal 7200rpm drive.
 
I have a Core i7 930 2.8ghz CPU with 12gb of ram (my motherboard's max is 16 so I figure it's not worth upgrading at this point until I just get a new computer)... I'm trying to squeeze it out until next summer/fall for my next computer haha. But I know it's getting close to that time.

Sound like we have similar systems except your clock speed is a little higher but I have my samples split over 3 ssd's.
 
I also run into the same issues on vsti heavy projects and I think the least expensive solution is getting a new PC with a higher clock speed. I am hoping to get one of Jims machines next spring but cost is always an issue.
 
Hoping you can find a inexpensive solution.