Here a crash, there a crash everywhere a crash crash....

[Robert Bone]

1) Sending in the dump was/is helpful to CbB support folks, and even more so if a good recipe for replicating a crash can be determined, and sent in to them as well.  

2) As noted by others above, that particular error is a pretty common thing - trying to access memory not owned by the application, in this case the plugin.  Things that can cause this are varied, and example would be if a memory pointer had not been valued - and contained all zeros, or wasn't repopulated properly due to falling through some set of If/Else conditions, and thereby executing code that should not have been reached in the normal programming logic.

3) If an error occurs within a plugin, there is pretty much no way for CbB to recover from it, as that plugin had control when the error occurred.  If the error had occurred in some location within Cakewalk, you would have almost certainly seen Cakewalk as the failing module, and an offset within the program, rather than the way this crash message was displayed, (with the plugin being named as where the error occurred).

4) AWESOME, that you were, however weird it was, able to workaround the error, by using the VST3 version of the plugin.  I have never before seen it go THAT way before - it has been (with some Waves plugins, mostly from what I recall), usually where a VST3 version fails but the VST2 version works.  Congrats for even thinking to try using the VST3 version, AND for it allowing you to keep working on your project, and moving it forward.

5) Even when SOME plugins have gone belly up in the past, there have been occasions where the Sonar support folks were able to tweak the Sonar code to have special code to deal with some failures within some failing 3rd-party plugins.  No guarantees this will happen here, or ever again - but it was pretty darned nice of those folks to do what they could to keep folks afloat by creating special logic to deal with some deficiency in one or more plugins that weren't their responsibility.

Bob Bone

 

[paulo]

4 hours ago, Robert Bone said:

4) AWESOME, that you were, however weird it was, able to workaround the error, by using the VST3 version of the plugin.  I have never before seen it go THAT way before - it has been (with some Waves plugins, mostly from what I recall), usually where a VST3 version fails but the VST2 version works.  Congrats for even thinking to try using the VST3 version, AND for it allowing you to keep working on your project, and moving it forward.

There was a known VST2 issue with Izotope Neutron in Sonar when that was released and the workaround until it was fixed was to remove the VST2 version and use VST3 version only, so I figured I'd try the VST3 and see what happened. 

Thank you for the explanation of the technical. I have no clue about that side of things.

CW have responded to say that they are on the case. Having been informed that using the VST3 version does not cause the same issue, Initial Audio seem content to leave it at that and show no apparent interest in investigating the issue further.

 

[paulo]

7 hours ago, bvideo said:

Just to set expectations for dump popups posted in the forum: There is very little in the popup that can be used by us users to "help the OP" with any substantial info.

Thank you for explaining. I thought that there may be something in there that would point the way to somebody in the know so figured it was worth a try before going down official channels and giving someone more work to do.

[msmcleod]

7 hours ago, bvideo said:

...

In this case it just confirmed the OP's observation that the crash probably happened while the plugin was processing parameters (or e.g. could have been processing audio while a parameter changed in an "inconvenient" way) after a freeze (which could be a clue as to why it would crash in one DAW and not another, given different or non-existent implementations of freeze). 

...

It's odd that this issue should occur when UN-freezing. Normally it would be the freeze that would cause the issue (as this is effectively a fast bounce, which some plugins have a problem with).

However, what I have noticed is that when you freeze a track, the memory usage goes down... I'm not sure if its right away in the same session, but certainly  when reloading a project with a frozen track, it shows less memory being used than the unfrozen version.

This leads me to believe that although the VST is shown in the synth rack, it hasn't actually been loaded if the track is frozen. Unfreezing the track then causes the plugin to be loaded.

So what you've said makes total sense.  Maybe CbB is setting the parameters too quickly after the unfreeze loads the plugin.

[chuckebaby]

22 hours ago, marled said:

IMO VST3 was more targeted as a randy thing for the developers than as an improvement for the DAW users.

Waves vocal rider, Melodyne's ARA interrogation. VST 3 wasn't just promotional hype.

https://www.cakewalk.com/Support/Knowledge-Base/2007013317/SONAR-X3-VST3-version-of-Melodyne-is-required-for-ARA-integration

[Starship Krupa]

5 hours ago, Robert Bone said:

when SOME plugins have gone belly up in the past, there have been occasions where the Sonar support folks were able to tweak the Sonar code to have special code to deal with some failures within some failing 3rd-party plugins

That is pretty cool, and what I consider "above and beyond the call." Of course every company has to  decide how they are going to handle this. Is the issue with the host's code or the plug-in's code?  Is the plug-in dev interested in coming up with a patch? How much will it cost to come up with a patch? Do enough users use the plug-in that it's worth bothering with?

It's funny what politics can come into play. (cough-cough) years ago I was on the QA team for a high-end photo editing program that was positioning itself as a challenger to Photoshop. Yeah, right? Well, if nobody had challenged Pro Tools, we wouldn't be here today.

Our program could host the same plug-ins that Photoshop could, and photo plug-ins are subject to the same kind of weirdness that audio ones are. They could refuse to load, crash, crash us, crash the whole system, etc. Some of these plug-in companies I've noticed, are still around today, doing some amazing work. The thing was, our programmers HATED anything to do with these plug-ins  with the fire of a thousand suns.

This was for a number of reasons. First, Adobe had "created" the spec to work best with Photoshop just like VST was "created" to work best with Cubase. When did Ableton start supporting VST? Only in their last revision or something? In Pro Tools you still need a 3rd-party wrapper? The truth with these specs is that especially at first they're usually pretty sloppily drafted, and they're drafted after the programmers at the company are already coding plug-ins. These are programmers who have access to every line of code in the host program, so they can do it without the spec anyway.

On the host side, what incentive do they have to make things easy for their competition? Just being nice? Is Steinberg  going to smooth the waters for Digidesign and Cakewalk and PreSonus and Ableton and ImageLine and Magix? Is it any wonder that so many rejected VST for so long? Cakewalk bet on DX, Digi went their own way, the others have their own proprietary systems and VST support is or was a premium option.

So outside Adobe, all we and the 3rd party plug-in devs had to go on was this roughly-drafted spec that may not have been drafted to encourage Adobe's competitors to succeed in the first place, knowhatimean?

Second, the people who had made these plug-ins only had Photoshop to work with and test with, and they were not that enthusiastic about possibly having a second program on the scene to make sure their products were compatible with. It was hard enough to work with Adobe. They had little interest in seeing us succeed.

Third, third-party add-ons in general are just a pain in the tuchus to deal with. Introducing elements over which you have no control into your system is inviting trouble.

What this all boiled down to was they would give us these great state-of-the-art plug-in packs to play with, and when they would crash the snot out of our program, our poor devs had no leverage whatsoever with the plug-in houses and their devs because their code had been burnished to a fine gloss to work smoothly with Photoshop. So any query about bad behavior was answered with "works fine  with Photoshop." Whether it obeyed the published spec or not, all that mattered was "works fine with Photoshop."

So hard to pinpoint the blame when a VSTi plug-in was coded using the Steinberg SDK and tested in-house and in beta in Cubase and Reaper and StudioOne and then the developer gets a report that CbB chokes after  their synth comes out of a freeze. CbB works fine with hundreds of other VSTi's  doing the same operation. Sektor works fine with  a dozen other hosts (if you flip the VST2/3 coin a couple of times). CbB probably didn't exist in its current form when the synth was developed. Whaddaya bet that the next rev of Sektor fixes this issue?

[Starship Krupa]

1 hour ago, Chuck E Baby said:

Waves vocal rider, Melodyne's ARA interrogation. VST 3 wasn't just promotional hype.

https://www.cakewalk.com/Support/Knowledge-Base/2007013317/SONAR-X3-VST3-version-of-Melodyne-is-required-for-ARA-integration

It doesn't necessarily follow that there was something in the VST3 spec that allowed Melodyne to incorporate ARA, it just means that Celemony went along with the VST3=more advanced technology narrative. It's also a convenient way to filter out older hosts, because no host that only supports VST2 is going to support ARA.

They might also have done it to get chummy or remain chummy with friends at Steinberg. I do you a favor now, you do us a favor down the road.

As far as Vocal Rider, I just took a peek at it, and as I suspected, it does its thing via sidechaining. VST3 allowed Waves to have a button called "Sidechain" in the VST3 versions of its plug-ins. If you look at the instructions for the AAX and AU versions of Vocal Rider, they give the non-PlaySkool version that most other plug-in companies still use, where the host automatically sees that the plug-in has external inputs and creates routing for them.

Nice position Steinberg was in: if the programmers of your host can't or don't want to figure out how to do that, like with Cubase and Nuendo, you can take the easy route (ha ha) and just come out with a new plug-in spec that forces the plug-in manufacturers to build sidechain routing into the plug-ins themselves. Make them do it for you!

When I went to Steinberg's page on the (B)ST3 "revolution" and read the part about how plug-ins were now going to  support this new thing "sidechaining," I had to stop for a moment and blink because I was wondering if they were talking about the same thing I had been doing for years. Nope, same thing, routing audio from a track to a plug-in on another track. Wow.

Look around on the DAW forums, and the only people who think that the advent of the VST3 spec rocked their world are Cubase and Nuendo users who say that sidechain routing used to be a big pain in the....sidechain. Everyone else says they work exactly the same except maybe they crash more, and some people are worried that eventually hosts will stop supporting VST2's and then their favorite plug-ins will be useless.

I like the VST3 spec for exactly one reason, and that is  because in practice at least, it seems to set a standard location for plug-ins. I don't know how well that works out for people with humongous VSTi sample libraries, but I don't like chasing .DLL's all over the place trying to find ones that wound up in C:\Program Files\Steinberg\Vstplugins or whatever. Waves' installers are great, funny even, for putting their plug-ins in every place a host is likely to look for them.

[Starship Krupa]

2 hours ago, msmcleod said:

However, what I have noticed is that when you freeze a track, the memory usage goes down... I'm not sure if its right away in the same session, but certainly  when reloading a project with a frozen track, it shows less memory being used than the unfrozen version.

This leads me to believe that although the VST is shown in the synth rack, it hasn't actually been loaded if the track is frozen. Unfreezing the track then causes the plugin to be loaded.

That's one of the goals of freezing an instrument/synth track, innit? Not only do you get the benefit of the FX' resources being freed up, you get the synth itself out of the picture as well. Not just the CPU, but I just checked what you said and CbB seems to be pretty good at unloading  the synth from memory.

I see that even the blessed Ref. Guide (BRG) doesn't do the best job of explaining this. It just says "to reduce the amount of CPU power needed," but thank heaven it extends to RAM as well. That's a dearer commodity around the Krupa household at the moment than CPU cycles. My CPU cores seem to mostly just sit around waiting for me to load an iZotope plug-in.

For the benefit of others, from my experience with other DAW's, what's supposed to happen with frozen tracks is you get a fully-rendered audio version of a track so that you can use it for mixing, overdubbing, whatever and not incur the overhead of whatever plug-ins you loaded on the track. The host should "park" any track FX or synths until you unfreeze it, resulting in more CPU and memory for the other tracks to play with. This parking happens in a variety of ways to varying degrees of effectiveness depending on the host.

Some hosts even let you decide what quality you want to use for frozen tracks, like you can use .OGG for frozen tracks in Mixcraft I think.

It's good for when you want to track a lead vocal at low latency with this huge virtual sampled orchestral backing. Bang, freeze everything to OGG Vorbis and Mixcraft has the resource footprint of an MP3 player while your singer is singing to the LA Philharmonic and a rock band with a zillion effects.

My hunch is that freezing an instrument track with FX is probably simple as things go, the DAW just needs to render a single track as it normally would and then unload the plug-ins. But un-freezing an instrument track seems like a task that would be fraught with a bit more danger. Depending on how the host turns the synth off, turning it back on might get weird. I've looked around and the only button for turning a synth plug-in on or off that I could find was in the Synth Rack, not in the Track Header or Console or plug-in UI. And what does this button do, exactly? Does it just grey out the UI or route audio around it or partially unload it from memory or what? It seems to reduce the memory usage a little more than freezing.

Do does the host turn on the synth first and then the FX, or the FX first, or what? Lots of decisions.

I tried to get some answers to these questions from other companies and crickets chirped. You know, stuff like "when I bypass a VST, does the audio route around it? Should I completely delete a VST from my plug-in rack to get it out of the audio path?"

[marcL]

On 6/11/2019 at 12:34 PM, Chuck E Baby said:

Waves vocal rider, Melodyne's ARA interrogation. VST 3 wasn't just promotional hype.

https://www.cakewalk.com/Support/Knowledge-Base/2007013317/SONAR-X3-VST3-version-of-Melodyne-is-required-for-ARA-integration

I don't know if it had not been possible to implement an ARA specification that was based on VST2 instead?! And you must admit that there are not many examples of plugins that really profit of VST3! ? There are even big plugin companies like NI that do not support VST3 until today!

[marcL]

On 6/11/2019 at 2:27 PM, Starship Krupa said:

I like the VST3 spec for exactly one reason, and that is  because in practice at least, it seems to set a standard location for plug-ins. I don't know how well that works out for people with humongous VSTi sample libraries, but I don't like chasing .DLL's all over the place trying to find ones that wound up in C:\Program Files\Steinberg\Vstplugins or whatever. Waves' installers are great, funny even, for putting their plug-ins in every place a host is likely to look for them. 

I really don't like the standard location for plugins ?, because

a) if forces all your hosts to have the same plugin list! (e.g. I don't need all my plugins in an audio editor or I want to avoid plugins that make trouble for one host only)

b) some plugin providers put their plugins directly into the VST3 folder (no subfolder) and if you have a lot of plugins this is really a mess having all in 1 folder. Additionally there are hosts that do not have a great plugin manager like CbB and for them it is sometimes an advantage to have a folder-organized plugin directory. Yes you can do it in the VST3 too, but because it is a "standard" location many installers do not give you the chance to define a subfolder location!

[abacab]

Did the original problem here with Sektor ever get sorted out?

[John]

On 6/11/2019 at 5:43 AM, paulo said:

Thank you for explaining. I thought that there may be something in there that would point the way to somebody in the know so figured it was worth a try before going down official channels and giving someone more work to do.

It is always a good idea to post as much information as one can. Too little and all it does is cause us to ask questions . There really never is too much information unless it has nothing to do with the problem. 

So you did nothing wrong in posting the dump file.  No need to think anything other then we are here to help as much as we can. There is no guarantee that we will solve a problem.  I can say that the members of this forum will try hard to find an answer. 

 

 

[paulo]

On 7/9/2019 at 11:41 PM, abacab said:

Did the original problem here with Sektor ever get sorted out?

No. I got an email from CW acknowledging that it was a problem and they were looking into it followed by  another 2 weeks ago saying "as we haven't heard back from you in a while" they would be closing the ticket. I have no idea what they were expecting to hear from me as I had already provided all the info I had and they had acknowledged that it was a problem that they were working on it. I replied straight away to that by asking why they were expecting further contact from me when as far as I was concerned I was waiting on them and also asking how a reported and acknowledged problem could be considered to be closed when the problem has not been solved. 2 weeks on and no reply to that......................I looked up the word impressive in my dictionary. It's definitely not that.

[abacab]

I bought Sektor on sale recently, and so far no crashes yet. I haven't tried freezing it, but I will follow up here if it does crash.

Fyi, I am on Windows 10, so that might make a difference too.

[abacab]

On 6/9/2019 at 5:41 PM, paulo said:

I haven't tried that, but to be clear it's not the unfreezing itself that causes the crash, but whatever  I do afterwards - ie change a parameter on the synth UI or playing a note on the keyboard. 

I will try this to see if I can reproduce the error.

[abacab]

5 minutes ago, abacab said:

I will try this to see if I can reproduce the error.

The VST2 crashed immediately after unfreezing and then opening the plugin UI and trying to play a new preset. Same exception error that @paulohad.

No problem with the VST3.