Everytime I click on PG-8X "Init" in the display, it instantly crashes and closes MuLab.
Can anyone repeat this?
Using PG-8X v2.0.13 x64 loads ok and loads presets, but crashes if you click it's display.
Tried with a fresh MuLab install, still crashes.
PG-8X crashes MuLab
-
- KVRAF
- 3139 posts since 28 Mar, 2008 from a Galaxy S7 far far away
-
- KVRAF
- 1925 posts since 29 Mar, 2013
Yes it does the same here, tried it with Mulab 9.6 with the same result so could be the synth.
edit
Just tried it with Cakewalk by Bandlab and it works.
edit
Just tried it with Cakewalk by Bandlab and it works.
Beauty is only skin deep,
Ugliness, however, goes right the way through
Ugliness, however, goes right the way through
-
- KVRAF
- Topic Starter
- 3139 posts since 28 Mar, 2008 from a Galaxy S7 far far away
-
- KVRAF
- 13851 posts since 24 Jun, 2008 from Europe
The crash is inside the plugin.
Best to report this to the plugin dev.
I'm open to the plugin dev to sort this out together via email.
Plugin dev can email me via
Best to report this to the plugin dev.
I'm open to the plugin dev to sort this out together via email.
Plugin dev can email me via
-
- KVRAF
- 1925 posts since 29 Mar, 2013
Ok, the synth hasnt been updated in a long time so I doubt its worth it to be honest. Thanks anyway.
Beauty is only skin deep,
Ugliness, however, goes right the way through
Ugliness, however, goes right the way through
-
- KVRAF
- Topic Starter
- 3139 posts since 28 Mar, 2008 from a Galaxy S7 far far away
-
- KVRAF
- 24403 posts since 7 Jan, 2009 from Croatia
Hmmm this doesn't crash in any host that I have here (Reaper, FL Studio, Live 12, Studio One 6, Reason 13, Bitwig 5).
There's something MuLAB is doing that other hosts don't deem needs to be done, that tickles the crash I guess.
This is again the case of basically abandonware plugin, so I'd say if other hosts don't have a problem with this plugin in the situation OP described... there would have to be a host-side workaround. Potentially this might be a similar case with Synth1, so could actually be the same cause...?
There's something MuLAB is doing that other hosts don't deem needs to be done, that tickles the crash I guess.
This is again the case of basically abandonware plugin, so I'd say if other hosts don't have a problem with this plugin in the situation OP described... there would have to be a host-side workaround. Potentially this might be a similar case with Synth1, so could actually be the same cause...?
-
- KVRAF
- 13851 posts since 24 Jun, 2008 from Europe
Yet the crash is inside the plug.
The fact that it does not crash in other hosts does not prove the bug is in MuLab.
It only proves that there are differences in host implementation.
And something that also counts is that MuLab still is rather unknown and so many plug devs don't yet take MuLab into account, they only take the popular hosts into account.
More strict SDK docs would be better for everyone!
That would result in fewer implementation differences on both host and plug side.
I'm always open to tweak/stretch MuLab's plugin engines to optimize/widen their compatibility, but when a crash is inside a specific plug then i'll need cooperation of the plug dev.
Atst i understood VST2 is dying.
I should rather minimize further investments in the VST2 plugin engine, in favor of other developments.
The crash in PG-8X is inside the plug's GUI functions, in the GUI thread.
The crash in Synth1 is inside the plug's processReplacing function, in the process thread.
I don't see any relation between that.
The fact that it does not crash in other hosts does not prove the bug is in MuLab.
It only proves that there are differences in host implementation.
And something that also counts is that MuLab still is rather unknown and so many plug devs don't yet take MuLab into account, they only take the popular hosts into account.
More strict SDK docs would be better for everyone!
That would result in fewer implementation differences on both host and plug side.
I'm always open to tweak/stretch MuLab's plugin engines to optimize/widen their compatibility, but when a crash is inside a specific plug then i'll need cooperation of the plug dev.
Atst i understood VST2 is dying.
I should rather minimize further investments in the VST2 plugin engine, in favor of other developments.
The crash in PG-8X is inside the plug's GUI functions, in the GUI thread.
The crash in Synth1 is inside the plug's processReplacing function, in the process thread.
I don't see any relation between that.
-
- KVRAF
- 24403 posts since 7 Jan, 2009 from Croatia
Hmmm... so I suppose the only thing that might explain this is that MuLAB is calling the host-side APIs in certain order that other hosts aren't?
-
- KVRAF
- 13851 posts since 24 Jun, 2008 from Europe
I can't answer that question as i don't have the source code of the other hosts.
I can tell you that i strictly follow the SDK docs.
I can tell you that i strictly follow the SDK docs.
-
- KVRAF
- 13851 posts since 24 Jun, 2008 from Europe
And most of the plugs work fine in MuLab, there only are some exceptions.
Possibly these plugs are specifically build upon a specific calling order of a specific host, instead of strictly based on the SDK docs. Just a possibility to also be taken into account.
Anyway, i'm totally open for concrete prove that there would be a bug in MuLab. That's always a possibility too of course. I like fixing bugs. But i need the clear tech prove. And i won't improvise on the SDK docs because then we're in the middle ages.
Possibly these plugs are specifically build upon a specific calling order of a specific host, instead of strictly based on the SDK docs. Just a possibility to also be taken into account.
Anyway, i'm totally open for concrete prove that there would be a bug in MuLab. That's always a possibility too of course. I like fixing bugs. But i need the clear tech prove. And i won't improvise on the SDK docs because then we're in the middle ages.
-
- KVRAF
- 24403 posts since 7 Jan, 2009 from Croatia
The problem with VST2 SDK was that the documentation was very inconclusive, which lead to many hosts AND plugin developers guessing how things should be, and some providing options for certain behaviors... So yes, middle ages indeed. That's VST2 for you.
For example, Reaper has an option "Buggy plugin compatibility mode", which can be set per plugin permanently. It forces buffers sent to and received from plugin to be powers of two, and also (controversially) makes GUI things run in audio processing thread, which can prevent deadlocks and crashes with some very naughty plugins...
(But this option is not enabled over here for PG-8X nor Synth1...)
For example, Reaper has an option "Buggy plugin compatibility mode", which can be set per plugin permanently. It forces buffers sent to and received from plugin to be powers of two, and also (controversially) makes GUI things run in audio processing thread, which can prevent deadlocks and crashes with some very naughty plugins...
(But this option is not enabled over here for PG-8X nor Synth1...)
-
- KVRAF
- 13851 posts since 24 Jun, 2008 from Europe
Indeed.EvilDragon wrote: Mon Apr 14, 2025 11:09 pm The problem with VST2 SDK was that the documentation was very inconclusive, which lead to many hosts guessing how things should be, and some providing options for certain behaviors...
Thx for the info.For example, Reaper has an option "Buggy plugin compatibility mode", which can be set per plugin permanently. It forces buffers sent to and received from plugin to be powers of two, and also (controversially) makes GUI things run in audio processing thread, which can prevent deadlocks and crashes with some very naughty plugins...
(But this option is not enabled over here for PG-8X nor Synth1...)
The Synth1 crash seems to happen as soon as it has to play more than 1 voice.
When playing a single note and let it fully release so its voice can end and then play another note then it does not crash, only when Synth1 voices get stacked.
This is with a 512 buffer size, which is a power of 2, so that won't be the reason.
I'm afraid that without help of the plug dev to sort the issue out it won't be fixable in a reasonable way.
-
- KVRAF
- 24403 posts since 7 Jan, 2009 from Croatia
Mmmm I see, it automutes (doesn't crash!) if you play more than one voice. BUT if you enable Unison, it works just fine, even with multiple keys pressed. Weird!
Unfortunate that the developer is completely out of the picture for over a decade now. But there's got to be something that makes it work just fine in other hosts... Hopefully eventually somehow gets figured out. I guess one way would be to have a small VST2 plugin that just does debug prints for every VST2 API call, so that one could trace in which order are things called in every host...
Unfortunate that the developer is completely out of the picture for over a decade now. But there's got to be something that makes it work just fine in other hosts... Hopefully eventually somehow gets figured out. I guess one way would be to have a small VST2 plugin that just does debug prints for every VST2 API call, so that one could trace in which order are things called in every host...
-
- KVRAF
- Topic Starter
- 3139 posts since 28 Mar, 2008 from a Galaxy S7 far far away
I have asked if there's any chance of a VST3 version, as well as fixing that bug for MuLab to use it.
I'm trying to move away from vst2 as much as possible, but this and synth1 was always a favourite with 17000 sounds it's a minefield of inspiration! Such a shame!
I'm trying to move away from vst2 as much as possible, but this and synth1 was always a favourite with 17000 sounds it's a minefield of inspiration! Such a shame!
Last edited by sl23 on Tue Apr 15, 2025 9:09 am, edited 1 time in total.