Mulab somehow seems to interfere with the open patch folder path I set up in Sylenth1. When I load an existing Mulab project and try to load a new patch in one of the Sylenth1 instances of the project, I sometimes get directed to the wrong folder (namely C:\...........\Documents\LennarDigital\Sylenth1\Presets , which is empty, though, as I don't use it for my patches), so I have to click a couple of times to get to my own patch folder every time, which is in a totally different directory on another drive. Very frustrating.
Adding a new Sylenth1 instance to the old project doesn't change anything, the path is still wrong.
If, however, I open a new project and load a Sylenth1 instance, loading a patch in it leads me to the correct directory and folder. The path to it is specified in Sylenth1's configuration file, of course.
Maybe it has to do with what Mulab saves in a project because the problem only occurs after loading a previously saved project. As I said, it only happens in Mulab, not in another DAW. So whatever it is, it seems to have to do with Mulab. Thinking about it,
since a Mulab project saves all kinds of synth parameters as project data (including synth patches that one has not saved as independent patches with names anywhere else, for instance modified patches), maybe Mulab ignores or overrides the Sylenth1 user settings that are made in the separate Sylenth1 configuration file (or maybe the link to that file gets deleted in the project), enforcing Sylenth1's factory settings instead (I think they do lead to that wrong folder under documents if I remember correctly, I modified them a long time ago).
Just an idea...
So, has anyone else observed that behavior?
I already contacted MuTools' helpful support some time ago, but he said it has nothing to do with Mulab. But I am not so sure, frankly ...
Anyone confirm a possible Mulab - Sylenth1 issue?
-
- KVRAF
- 12739 posts since 24 Jun, 2008 from Europe
You're talking about the file browser within the Sylenth GUI. MuLab has no control over what happens inside a VST plugin's GUI.
Also note that the data that a VST plugin saves into the host project is just a block of bytes, the host does not know what these bytes mean, only the plugin knows the meaning of these bytes.
Did you ask this question in a Sylenth support forum already?
Also note that the data that a VST plugin saves into the host project is just a block of bytes, the host does not know what these bytes mean, only the plugin knows the meaning of these bytes.
Did you ask this question in a Sylenth support forum already?
-
- Banned
- Topic Starter
- 3564 posts since 22 Aug, 2019
No, I haven't. Since it only happens in Mulab so far, I think it is more likely a Mulab issue than a Sylenth1 issue.
But if nobody else here has the issue, I might ask on the Sylenth1 forum as well later on...
But if nobody else here has the issue, I might ask on the Sylenth1 forum as well later on...
-
- Banned
- Topic Starter
- 3564 posts since 22 Aug, 2019
Seems it was something about Sylenth1 after all. Its developer has provided me with a modified version for testing purposes, and the wrong path issue seems to be gone now.
He also changed the behavior where saving a patch under a new name did not update the patch's old name in the display accordingly.
I suppose he will release the update soon.
He also changed the behavior where saving a patch under a new name did not update the patch's old name in the display accordingly.
I suppose he will release the update soon.
-
- KVRAF
- 12739 posts since 24 Jun, 2008 from Europe
-
- Banned
- Topic Starter
- 3564 posts since 22 Aug, 2019
I still don't quite understand how such an issue can be present in one DAW, but not in another 
Now my only remaining gripe with Mulab is that it clearly taxes the CPU much more.
Now my only remaining gripe with Mulab is that it clearly taxes the CPU much more.
-
- KVRAF
- 12739 posts since 24 Jun, 2008 from Europe
-
- Banned
- Topic Starter
- 3564 posts since 22 Aug, 2019
This is his explanation:
The path was stored in a shared variable, so depending on how the DAW would clear the memory after deleting an instance it might or might not be still there.
I've changed it to store locally in each instance, so it works fine now!
The path was stored in a shared variable, so depending on how the DAW would clear the memory after deleting an instance it might or might not be still there.
I've changed it to store locally in each instance, so it works fine now!
