Omnisphere Recent Update

[4th Eden]

It seems our output silence/vst scrambling  issue is related to the most recent Omnisphere update. This release was early June. I've since loaded an old dll of Omnisphere from January (not ideal) and this works. 

Whether the latest update to Cakewalk has made the Omnisphere dll unstable is unknown. Its only when I went back to a project pre-June Omnisphere release did I realise that there was an issue. I cant confirm though if this affects projects that use Trilian or Stylus RMX yet.

[Andres Medina]

Trilian (1.6.0f*)  and Stylus (1.10.0f*) working fine here. 

Omnisphere I working here (1.5.8.d 64 bits). But this version was not updated.

[4th Eden]

13 hours ago, Andres Medina said:

Trilian (1.6.0f*)  and Stylus (1.10.0f*) working fine here. 

Omnisphere I working here (1.5.8.d 64 bits). But this version was not updated.

Its 2.7.0f now...youll be fine! This is only a problem 1. if you have installed the June Omnisphere patch and 2. gone back to older project using prior to 2.7.0f

[Andres Medina]

1 hour ago, 4th Eden said:

Its 2.7.0f now...youll be fine! This is only a problem 1. if you have installed the June Omnisphere patch and 2. gone back to older project using prior to 2.7.0f

Thanks.. I´ll do it - I work a lot with Spectrasonics plugins.

[Smokey Toobs Sr]

Hmmm...I've updated OmniSphere, Cakewalk, and Windows 10, plus I'm still working on projects from May. I guess I've been lucky...no problems have come up yet !! But, if I run into problems, thank's for posting this, Andres !!!

?  

[msmcleod]

I tried the upgrade using both older projects and also a test project I made just before I upgraded.

I didn't get any issues, but then I can't remember if I'd actually upgraded to the early June or not.  It's possible (if not likely), that I was on the previous version before upgrading.

[bitflipper]

I missed the 2.7 announcement and wasn't even aware of the update (running ver. 2.6 here), so thanks for cluing me in. Yeh, I know, it clearly says "updates available" every time you start it up. Situational blindness, I guess.

I have current projects that use Omnisphere, Trilian and Keyscape. I'm going to update them this weekend and see if there are new problems, then post back my results.

[EDIT]

I couldn't wait for the weekend. Omnisphere is too important to me to not know if it has a problem. Don't know if this is good or bad news, but I just played back a project with 16 patches in a single Omnisphere instance and there were no discernable problems. How could that be bad news? It is if you're trying to replicate a problem. Sorry, I could not.

[bitflipper]

Could you describe the symptoms of the "output silence/vst scrambling" issue?

I just had a bizarre thing happen in this Omnisphere-heavy project: an instance of Kontakt went silent after updating Omnisphere. Weird. I hesitate to bring it up here, as it might be off-topic. The problem turned out to be a routing issue - the Kontakt audio track's input source had been switched from Kontakt to another synth (Zebra2). I can't imagine a scenario in which I could have accidentally done that myself, and the cross-routing had to have occurred within the last hour.

[dantarbill]

3 hours ago, bitflipper said:

...The problem turned out to be a routing issue - the Kontakt audio track's input source had been switched from Kontakt to another synth (Zebra2). I can't imagine a scenario in which I could have accidentally done that myself, and the cross-routing had to have occurred within the last hour.

I've seen this before...not like a lot...but I've seen it.  Typically, it happens when opening legacy projects.  It's been occurring occasionally for years with multiple versions of SONAR/Cakewalk.

[bitflipper]

Update: I have now seen this problem in at least six recent projects, with mis-routed audio inputs on many dozens of tracks. All of them had been last opened before I updated Omnisphere.

I wouldn't have thought that updating a VI could screw up a project's routing, but that does appear to be the case.

In at least one instance, the routing change was to a frozen track, which could not be un-frozen without crashing the synth (Zebra2) it had been connected to when frozen. I was able to salvage the project by removing the synth and inserting a new instance.

[Andres Medina]

Same here: I opened a project containing Omnisphere, and all the inputs+outputs of the audio tracks of the plugin were completely mismatched. Only happened with Omnisphere. Not sure, but perhaps the last time I opened the project was before updating Cakewalk.

 

[bitflipper]

Checked the release notes, and sure enough there it was, the smoking gun:

Quote

Adds a ninth audio output bus, labeled "OUT I" in the Output Assignment menu for each Part on the Mixer page

I asked Noel if changing the number of outputs in a VI update could corrupt a project, and he said yup.

Bottom line: do not reopen any Omnisphere projects created before June 2021 and you'll be fine. If you must revisit an old project that has Omnisphere in it, be prepared to perform extensive repairs. And if one of the affected tracks is frozen, leave it frozen to avoid subsequent crashes.

[Noel Borthwick]

Seriously they added a new output to the existing synth in an update? Does nobody care about backwards compatibility? I guess nobody there actually tests their plugins in Cakewalk or they would have caught this immediately.
Port routing in Cakewalk is based on the counts of outputs from hardware and virtual instruments. Port are a range of integers that include the entire set of instrument outputs. When you add or remove instruments we manage that namespace of ports by adding and removing items. But if a plugin does this behind our back it will mess up the ports in the project because the numbers will be off by the number of ports added or removed.

 

[bitflipper]

I have to imagine CW isn't the only DAW that works this way. Could be that Spectrasonics just tests Logic and Pro Tools and calls it a day.

But QA aside, I am surprised that the coders didn't anticipate this, as changing a DLL's interface almost guarantees broken backward compatibility. That's Programming 101. Then again, the whole reason for VST's existence is to implement standardized interfaces, so the programmers might be forgiven for forgetting that rule. OTOH, that's why QA exists - to test if what the programmer thinks will happen really does.

[Andres Medina]

Thanks for the research!

Now it all makes sense (kind of..!).

And yes, the only way to restore the project is to manually assign each audio input all over. For one instance, it's just 8 outputs to go. But for multiple instances, well... hard work.

[Noel Borthwick]

31 minutes ago, bitflipper said:

I have to imagine CW isn't the only DAW that works this way. Could be that Spectrasonics just tests Logic and Pro Tools and calls it a day.

But QA aside, I am surprised that the coders didn't anticipate this, as changing a DLL's interface almost guarantees broken backward compatibility. That's Programming 101. Then again, the whole reason for VST's existence is to implement standardized interfaces, so the programmers might be forgiven for forgetting that rule. OTOH, that's why QA exists - to test if what the programmer thinks will happen really does.

VST doesnt spell anything out which is why there is this mess of incompatibilities.
Kontakt solves this by always exposing a large pool of outputs and even though you can change assignments that is done INSIDE Kontakt and transparent to the DAW.
I spoke to a dev there and he said that they never change the output routing even through the VST interfaces because its very poorly supported in DAW's.

[Noel Borthwick]

11 minutes ago, Andres Medina said:

Thanks for the research!

Now it all makes sense (kind of..!).

And yes, the only way to restore the project is to manually assign each audio input all over. For one instance, it's just 8 outputs to go. But for multiple instances, well... hard work.

Yes its a shame that they didn't test their code in Cakewalk. I will look into whether its possible to detect a mismatched output count at load time and do some internal surgery to the project. No promises because that is really convoluted to do and honestly I would prefer spending that time on other more important things.
The plugin could trivially have checked if the persisted version was earlier and NOT exposed the extra output in that case.

[Andres Medina]

That would be great - Thanks Noel.

[bitflipper]

Or, if it's no big deal to simply detect a change, just a warning messagebox would have saved me a week of head scratching. Like "WARNING: This version of _______ may be incompatible with this project."

[Noel Borthwick]

We posted a new early access installer that includes a fix for this issue. @bitflipper @Andres Medina please try this out and let me know if this addresses the issues with I/O's getting changed unexpectedly.
AFIK the problem was only localized to track inputs when loading a synth that changes its outputs. Let me know if you still see problems with this fix.

On 7/21/2021 at 10:34 PM, Andres Medina said:

Same here: I opened a project containing Omnisphere, and all the inputs+outputs of the audio tracks of the plugin were completely mismatched. Only happened with Omnisphere. Not sure, but perhaps the last time I opened the project was before updating Cakewalk.

 

I'm confused by the statement that inputs and outputs were mismatched. Are you referring to the outputs to buses from tracks? Those should have been unchanged. Anyway let me know how it works in this release.