Does anyone still use Synth1?

[MuTools]

What could it possibly be that makes it work in ALL the other hosts just fine?

I really have no clue.
I'm flabbergasted by that too.
And it's frustrating that this is regarded as a MuLab bug while this has not been proven, and based on my technical intuition i rather think it's something on Synth1 side. (while i stay openminded for the opposite prove)

But with the eye on making music: Aren't there good alternatives to Synth1 nowadays?
Maybe even using MuLab's own modular synth & effect system?

[EvilDragon]

Well it has dozens of thousands of patches available for it. It's kind of like a DX7 in that regard. So, for those patches, and the way they sound, there's not an easy replacement...

From the last test i remember it's indeed a crash.
A crash deep inside the Synth1 code, like 10 functions deep, starting from processReplacing.
Only occurring in the 64 bit version when playing more than 1 polyphone.
IIRC.

Mmm it actually doesn't take down MuLAB. It just stops producing audio. In MuLAB's rack the plugin gets automuted (red light), you can disable it then reenable it and it makes sound again. Maybe a NaN?



I am not necessarily saying the bug is on MuLAB side. But just that there is something different in the way MuLAB hosts VST2s that uncovers this particular bug in Synth1, which other hosts don't, for whatever reason...

[MuTools]

Well it has dozens of thousands of patches available for it. It's kind of like a DX7 in that regard. So, for those patches, and the way they sound, there's not an easy replacement...

Yes i understand that aspect.
That's also why i would like to see this fixed as Synth1 indeed is a nice free musical tool.

Mmm it actually doesn't take down MuLAB. It just stops producing audio. In MuLAB's rack the plugin gets automuted (red light), you can disable it then reenable it and it makes sound again.

That's because MuLab catches the exception (crash) and switches off the plugin in order to protect the user's creative work. But in debug mode i see it's a crash deep inside Synth1.

Maybe a NaN?

I don't know what causes the crash inside Synth1.
Only the plug dev can see that.

I am not necessarily saying the bug is on MuLAB side. But just that there is something different in the way MuLAB hosts VST2s that uncovers this particular bug in Synth1, which other hosts don't, for whatever reason...

Yes i do feel you are talking technically carefully about this, thank you for that.
I just need to emphasize the "it works in other hosts does not mean it's a bug in MuLab" aspect towards others reading this topic. And to be clear: I'm not stubbornly protecting myself from work. If i would know it's a bug in MuLab it would have been fixed already.

[EvilDragon]

If I were any good with reverse engineering I would have already been in deep forests with Ghidra...

[EvilDragon]

Oh hey, Jo, look at this, I found that it also crashes the JUCE AudioPluginHost. And somebody else has stumbled upon it, as well... Looks like using the linker flag /DYNAMICBASE:NO when building the host on Windows might be the answer!

https://forum.juce.com/t/crash-in-call- ... in/56933/4


I think Synth1 likely uses some fixed memory offset or a raw pointer directly somewhere in processReplacing() code (all in the name of CPU efficiency!), and memory address space layout randomization f**ks it up!


I am opening bets that this might actually also fix the crash with PG-8X (because it crashes in the same way in JUCE AudioPluginHost, by clicking on the LCD display area)!

[MuTools]

Thx for the link EvilDragon, i'll follow that up soon.
(Currently focused on another big programming job and best to keep focus)

[EvilDragon]

Wow, amazing, it's actually completely true. I just built JUCE AudioPluginHost with that linker flag set, and it fixes BOTH Synth1 AND PG8X crashes!!!

@sl23 There is hope!!


Now I wonder if it might also fix the Roland VST3 plugins, as well, bwahaha!

[sl23]

That would be amazing if it did.
I had a thought, maybe not a great one dev-wise, but may help to big up MuLab a bit...
What if MuLab could load those synth1 patches?
Imagine having that arsenal available in MuLab!!!
I expect there's copyright involved, so can't include them in the MuLab package, but the fact they could be loaded, even if they sound slightly different from the original, it gives MuLab a massive library of sounds that are mostly freely available on the net.

[EvilDragon]

All those patches are free banks, there's no copyright involved. But how close could it be sound-wise? That's the question.

[syntonica]

Synth1 has a good 100 or so parameters. It would be huge to build in Mulab. As well, getting the oscillators, filters, etc. to sound right would be nigh impossible without a lot of reverse engineering or access to the source code. It would be a terrific built in synth for any DAW, however. Defitely better than a lot of stock plugins.

Forgot to add: isn't Synth 1 patch compatible with the Nord 2? 3? I forget...

[EvilDragon]

It was inspired by Nord Lead 2(x) as far as feature set, but doesn't sound like one and doesn't import its sysex IIRC.

[sl23]

Looking at a factory preset, it doesn't look too hard to figure out what does what, just time consuming, but I'd be willing to work out what the numbers are. Then it's just a matter of reading the file and setting each value to a parameter in MuX, which is the hard part? I'm no dev so don't know on that, but I imagine tricky to do?

I'm also not great at creating Mux presets. I know the basics, but am stuck on several aspects:
1. How to add detune function and knob for Osc1.
2. How to add FM function and knob for Osc1.
3. How to set up Sync function and knob for Osc2.
4. Can an arpeggiator be made in Mux?

I have made a start but need some help with these if anyone can help please.
One thing I may need is something from Jo, I have created buttons using a Parameter Value Randomiser, but am stuck at 8 buttons due to it's limits.
FR: I think it would be useful to increase this to 32.
However, I expect my lack of knowledge means there's ways around it? Again, if anyone can help please do.
Thanks for your time.

[MuTools]

Wow, amazing, it's actually completely true. I just built JUCE AudioPluginHost with that linker flag set, and it fixes BOTH Synth1 AND PG8X crashes!!!

Ok i made a MuLab build with DYNAMICBASE:NO.
Both Synth1 and PG-8X indeed work fine then.
So this is a 100% prove that the bug is inside these plugins.
These plugins assume something that should absolutely not be assumed.
Bad memory usage design.

Using DYNAMICBASE:NO is generally disrecommended as it makes an app less secure.
DYNAMICBASE:YES is the default for new MSVC projects.

I'm amazed having to conclude that 'all other hosts' are using DYNAMICBASE:NO. (possibly only in their plugin sandbox?)
Amazing as that's not only a worse build setting, but also:
Where did all other host devs find that info to deliberately switch off DYNAMICBASE to NO as the default Visual Studio build setting is DYNAMICBASE = YES!
It surely is not mentioned anywhere in the VST2/VST3/CLAP SDK.

Now i'm left with a difficult dilemma: Should i choose to build MuLab with a less secure build setting to support a couple of old VST2 plugins?
Or should i keep the modern build setting but receive more false criticism like "Synth1 doesn't work in MuLab, but it does work in all other hosts, so this is a MuLab bug." ?

From technical pov these plugins have a bad memory usage and MuLab should keep the best build setting.
From musical pov MuLab could step back in time, like 'all other hosts' and use that less secure DYNAMICBASE:NO.
But aren't there any bad side-effects of switching to DYNAMICBASE:NO ?

I hate such chaotic improvised coding aspects. Code tech should be absolutely clearly defined and unambiguous. I'll need reflection time and advice for taking this decision.

Last but not least: Thanks a lot EvilDragon for finding and sharing the hotspot in this technical topic

Now I wonder if it might also fix the Roland VST3 plugins, as well, bwahaha!

Unfortunately not.

[audiojunkie]

Wow, amazing, it's actually completely true. I just built JUCE AudioPluginHost with that linker flag set, and it fixes BOTH Synth1 AND PG8X crashes!!!

@sl23 There is hope!!


Now I wonder if it might also fix the Roland VST3 plugins, as well, bwahaha!

Great discovery!!!

[audiojunkie]

Wow, amazing, it's actually completely true. I just built JUCE AudioPluginHost with that linker flag set, and it fixes BOTH Synth1 AND PG8X crashes!!!

Ok i made a MuLab build with DYNAMICBASE:NO.
Both Synth1 and PG-8X indeed work fine then.
So this is a 100% prove that the bug is inside these plugins.
These plugins assume something that should absolutely not be assumed.
Bad memory usage design.

Using DYNAMICBASE:NO is generally disrecommended as it makes an app less secure.
DYNAMICBASE:YES is the default for new MSVC projects.

I'm amazed having to conclude that 'all other hosts' are using DYNAMICBASE:NO. (possibly only in their plugin sandbox?)
Amazing as that's not only a worse build setting, but also:
Where did all other host devs find that info to deliberately switch off DYNAMICBASE to NO as the default Visual Studio build setting is DYNAMICBASE = YES!
It surely is not mentioned anywhere in the VST2/VST3/CLAP SDK.

Now i'm left with a difficult dilemma: Should i choose to build MuLab with a less secure build setting to support a couple of old VST2 plugins?
Or should i keep the modern build setting but receive more false criticism like "Synth1 doesn't work in MuLab, but it does work in all other hosts, so this is a MuLab bug." ?

From technical pov these plugins have a bad memory usage and MuLab should keep the best build setting.
From musical pov MuLab could step back in time, like 'all other hosts' and use that less secure DYNAMICBASE:NO.
But aren't there any bad side-effects of switching to DYNAMICBASE:NO ?

I hate such chaotic improvised coding aspects. Code tech should be absolutely clear and unambiguous. I'll need reflection time and advice for taking this decision.

Last but not least: Thanks a lot EvilDragon for finding and sharing the hotspot in this technical topic

Now I wonder if it might also fix the Roland VST3 plugins, as well, bwahaha!

Unfortunately not.

Is there a way to make it an option? Ideally, could be used on a per vst basis? This would solve everything--it would stop people from complaining about MuLab, and It would allow the user the choice of enabling it themselves (it could be defaulted to off). Or, is this something that has to be set at compile time? When you say that it is "less secure", are you referring to the ability of someone to hack into my computer, or are you referring to the stability of the system somehow? If it doesn't reduce stability, I have no worries about someone hacking into my system--I use Linux. That is.....unless it has a negative effect on running in WINE.