I can´t confirm this. I´ve been on 44,1kHz all the time and had multiple issues.
Lots of random crashes and also the fact that OP-X Pro II won´t recall the right presets often times.on rackspace changes. Sometimes it works, sometimes not.
First response from Peter of SonicProjects was that he has been in contact with Gig Performer developers in the past because of similar issues, and that it may have been related to an update/change in the libraries of JUCE.
I hope they will look into it more detailed.
Is there any info in the crash dump which could give a hint to potential issues in OP-X Pro II?
I concur on the random patches being recalled. Let’s keep the pressure on Sonic project as this is clearly their problem and not GP. I’ve got 30 some odd plugins with GP and it’s rock solid. This is the only plug-in I have that is awol.
If I understand well the crashes occur randomly and not at a specific time, right ? (when loading, when switching to the OP-X II rackspace, when playing…)
It is not clear to me what the “preset” recall issue is. Do you try to change the presets of OP-X Pro II live or do you have difficulties to recall the plugin states? Could you please describe a bit better what the problem is?
Could somebody facing the issue post a VST or VST3 based gig file involving only OP-X PRo II with typical steps to reproduce the issue? (coudl it be that issues only occur when the plugin is used in several rackspaces?)
David - I received an email back from Peter of Sonic Projects. OP-X still crashes with a sample rate of 44.1K (allbeit less than running at 48K though). WITH A SAMPLE RATE OF 44.1k: The crash (in my case) happens when I play the 1st note is played of some OP-X plugins. WITH A SAMPLE RATE OF 48K: The crash happens when GP tries to load the 1st rackspace that contains OP-X.
In regards to the “preset” issue, when multiple rackspaces of OP-X are in a gig-file (let’s use 5 as an example), sometimes the 3rd OP-X rackspace will load with the 2nd OP-X rackspace preset. So it’s not really “random”, but rather loading the last OP-X preset that was used in a previous rackspace. This doesn’t happen all the time – and maybe related to OP-X presets that are NOT in the default preset bank. Reading their FAQs, there is a statement about only being able to load default bank presets upon initialization – and in my case – I have some rackspaces with downloaded OP-X preset banks. – So if OP-X can’t load an alternate bank during initialization – it just takes the last preset that it loaded successfully (At least that’s my understanding of this).
In regards to OP-X Crashing GP, this is this is what Sonic Projects has stated:
Yes, we recently received a similar report from another user. Thanks for the report.
As I already told the other user there was a similar issue two or three years ago which turned out to be caused by a change in the JUCE-library (IDE GigPerformer uses) which handles some events more strictly as needed. Back then, the issue again had gone with an update of JUCE - and now it’s obviously back.
It’s an issue related to the patch manager of OP-X PRO-II which sends some data from DSP directly to the GUI, which unfortunately can’t be changed easily without completely replacing the whole patch manager - which we however plan to do, also for other reasons. Nevertheless, other non-JUCE-based hosts and sequencers including Logic, Live and Cubase don’t have this issue, so it COULD be fixed in JUCE I think. Why treat events strictly when things are working well without doing it.
So we’ll for sure try to fix it asap. But it won’t be that easy unfortunately.
I’m not sure what he means by this but if he is in fact actually calling GUI functions directly from the audio process handling, that’s an absolute NO NO as far as I’m aware.
While other DAWs may handle this, they don’t need to be 100% real time like GP so they can probably afford to put some extra “wrapping” around these calls.
Nebojsa may have even more insight — he understands that aspect of the system very deeply.
JUCE is not an IDE and changes in it are not the reason for these issues or every plugin would be failing.
If this is the case and GUI is attempted to be manipulated from a non GUI thread then I’m sorry to say that SonicProjects will have to fix this as it is really not acceptable. Fixing it should be trivial btw…
It may look like they don’t have this issue, but those DAWs are not loading multiple instances of this plugin nor are they doing what GP is doing which basically makes this argument irrelevant. There are many other DAWs that could be failing in the same way. Race conditions, speed of computer and other such factors can exacerbate or hide these kinds of problems.
This is also indicative or poor implementation/design. A sample rate should not be changing the stability of a plugin or the entire system. What happens at 96kHx ?
All of this is really irrelevant if an attempt is made to modify GUI from a non-GUI thread. Sometimes it may work on some platforms and some languages, but proper multithreaded programming is a hard topic even for some seasoned programmers. One of the first rules is “don’t change the UI elements if you’re not working from a UI thread” and that has nothing to do with audio programming, plugins or DAWs.
I love OP-X Pro II but I had to give up on it after years of stability and functionality issues. It was unusable in GP in Windows because of the constant crashes. I had hopes when I switched to a Mac, but it wasn’t much better (still have the preset saving issue). So I gave up and now use the Arturia one.
Yes everyone has this issue. You save and GP crashes. We went through this issue before in the community. It is on OPX side. They are updating a live programming thread which someone said was a bad no-no. They told me that they would be rewriting their plug-in to use a different include file which would clear the problem
That’s not what I meant with reproducible. I was asking for a step by step procedure to make this loss of state or this crash happen.
I am using this plugin in a Rackspace right now, and while I never had a crash, I observed a loss of plugin state one time. But, since then, I cannot reproduce it anymore.
On the “loss of state” issue – I have a rackspace where I use four instances of the OP-X Pro II plugin. And as mentioned above, the behavior is somewhat random, but it has become a persistent problem.
Often the plugin switches to the default bank with the correct patch I had selected simply swapped in as the first preset in the default bank. But on other occasions (as noted above) the plugin switches to the default bank and just loads the last used preset patch from another instance of the plugin rather than the preset I had previously selected and saved in this instance.
I’m wondering whether it might help to build a new default bank, and have the presets I use all loaded into the new default bank. But no idea whether that would help. Has anyone figured out a way to make this stable? Thanks
There’s really nothing you can do from the GP side. GP requests the state from the plugin, it’s essentially a binary chunk of data that GP simply saves without any interpretation. When the gig is reloaded, GP simply sends that chunk of data back to the plugin. This mechanism is well defined in the VST specification.
If the plugin doesn’t deal with it properly, that’s on the plugin.
Probably not that random. Hopefully some specific steps lead to this issue. As I already mentioned, I had once this issue in a rackspace, but for the moment it doesn’t happen anymore. We have to find a reproducible step by step procedure for Sonic Project to fix it.
I know, already got the Arturia OP-Xa the Cherry Eight-Voice and the Discodsp OB-Xd
However I was surprised by the very good quality sound patches (“Famous-Bank”) of the SonicProjects OP-X-Pro-II. They are really good - maybe the other companies should hire the sound designer to gain more interest in their models
I meanwhile did a demo installation to see how they really feel compared to the demo tracks and YT videos on their webpage. Absolutely great sounding!
The installation is ‘interesting’ - so far everything works - however I’m not planning to use this plugin in my live rig for the moment with the comments above…
