MuLab 10.1.25

Official support for: mutools.com
Post Reply New Topic
RELATED
PRODUCTS

Post

Maybe it was a MuLab issue and has been fixed meanwhile.
Maybe it was a plugin issue and has been fixed meanwhile.

Post

Dunno, will let you know if it happens again though :tu:

Post

To add to sl23's observations, I initially found this bug to affect the plugins OTT and DJMFilter predominantly, as well as occasionally Serum (1 and 2) and Vital, so I thought maybe it was related to that somehow, which to me didn't add up since they didn't used to have issues in the past. This started occurring only once I upgraded my projects to M10.
Hello, everyone! :)
SoundCloud
Bandcamp

Post

FYI: That bug is not plugin related.
BUT: As soon as any modules (eg. plugin) are used that use any latency, the chance raises that the bug pops up lateron in a MuLab session. (MuLab session = from MuLab launch to quit)

I had a quick look at the M9 and M10 codebases and looks like you're right that this bug sneaked in during M10 development.
Anyway it will be fixed soon.

Post

Hopefully it's the same issue I had :)

Post

Just going through all my projects to update Uhbiks to VST3 and found an old project that still has the issue discussed above. Though this project doesn't have the issue with W1Limiter alone, as can be seen in the GIF, the MUX also has the same issue. Disabling the MUX or W1Limiter then enables the audio to pass through.
GIF 29-09-2025 15-16-01.gif
I will send the project via email, I have removed everything except the first two tracks with the issue. It may be that the issue has been fixed, but I will send just in case it isn't.
You do not have the required permissions to view the files attached to this post.

Post

Replied via email.

Post

I sent email. Just wondering, did the project work ok your end?
Btw, it always seems to be the last plugin/MUX in the rack that causes the issue, at least for me.

Post

I hope someday MuLab users become less fixated on plugin-related features, and more fixated on unique music-related features.
F E E D
Y O U R
F L O W

Post

Michael L wrote: Tue Sep 30, 2025 12:47 am I hope someday MuLab users become less fixated on plugin-related features, and more fixated on unique music-related features.
Its a squeaky wheel issue. Plugin-related features are an industry standard. Music-related features don't matter, until they become an industry standard; or they are easy to fit in.

Features that come from a (creative inspired) day dream aren't important; till they catch on. So, you are a day dreamer, not a squeak. Hence, no rush to the fire.

But, if you can do it over there, there too, but not here.... its bloody catch up time.

As annoying as it is, it is the commercial game. Fortunately, the committed day dreamers find a way. The key, is for that manifest art to gain popularity. When people hear the unique sound, the demand for adaptation to that artist's technique arises.

The question/issue is, does the adaptation forge a mold/casting or open a door for even more inspiration? Its great to make the artist's work easier; but very boring to just help others duplicate that artist's present trending quirk. One way is guaranteed to make you money; while the other only makes you money, if you do it just right ( and it is realized/exposed as that! ).

MuLab needs artists using the unique abilities MuLab supplies, and said artists gaining attention for it. The influencer thing sucks, but it is the thing. Even a couple independent ( YT channel posting ) studio producers giving a shout-out, to MuLab, would make a difference.

Dangerous waters, though. For very good thing one person says, two others will tear you up. But, sometimes being in the running is better than not being known at all. Red Team/Blue Team, Dem/Rep, Ford/Chevy, Coke/Pepsi, etc.

Not being on Linux isn't that bad. The Linux user share is still pretty low. MuLab is pretty portable, it isn't invasive to your system, it isn't extremely heavy, it is as simple or complex as you need it to be, and it is affordable. These are all good things, but the competition does all of those things oppositely. With something like EnergyXT, it was fitting for what that DAW was. Here, MuLab is a lot more refined. People need to be exposed to the reality, that a program under 2.5-3.5 GB (installed) is a strength.

That, or else we need to pander to commercial standards.

Ahhhh....

On with the Beta! :)

Post

Shows that prejudice is impossible to escape from.

Post

Is there anything that can be done regarding Automation when changing Rack slots? Currently it loses the Target Module and automation needs to be reassigned.

Post

MuLab App M10.1.9 beta for Mac+Win64 is available on https://www.mutools.com/mulab/app/lates ... /beta.html

MuLab Plugin M10.1.9 beta for Mac+Win64 is available on https://www.mutools.com/mulab/plugin/la ... /beta.html

What's changed:
  • When working a longer time with MuLab, possibly on multiple projects, and there were modules using process latency, then it could happen that after loading a project/preset a random module unexpectedly stopped processing audio. This was a very erratic bug, difficult to repeat, and quite annoying as it at least needed a (save+) reload of the project, or a MuLab restart. Thanks Pellet Project for isolating this bug. Fixed.

Post

sl23 wrote: Tue Sep 30, 2025 9:03 am Is there anything that can be done regarding Automation when changing Rack slots? Currently it loses the Target Module and automation needs to be reassigned.
I quickly doublechecked this:

* New project
* Draw sequence for Basic Synth
* Draw automation for Basic Synth Filter Decay Time
* Plays all fine
* Move Basic Synth to slot below
* Still plays all fine incl automation

So i don't know what you mean.
Please list a step by step that repeats the issue starting from a new project using Basic Synth.

Post

Ok, I can't repeat it. But the name of the automation lanes changes from Slot 2: Uhbik Runciter to Rack Slot 2 when moving the plugin from slot 2 to slot 3. Automation remains intact. Shouldn't it keep the name and change position to Rack Slot 3? Only a minor thing but still...

If the other issue appears, I will come back to you on that. Seems intermittent when moving them that automation gets lost.

I then tried moving the plugin to slot 3 and adding a new plugin into slot 2, this changed the target to Slot 2: TAL Reverb 4. Automation lost due to Target Module change. I wasn't sure how it was meant to work. Should Automation be tied to the Slot or the Plugin? Personally, I would suggest the Plugin, as this instance shows, the TAL Reverb doesn't respond to the automation for obvious reasons.

This is likely where I noted earlier that the Target and Automation Type were blanked. I think it was where I added Runciter VST3, removed Runciter VST2, then moved the VST3 up one slot in the rack, thus appearing that it caused the removal of the Target and Type for automation.

Anyway, the upshot of it is that I believe that automation should follow the plugin? I don't know if that is possible or not though? I just thought I would mention that. :tu:

Post Reply

Return to “MuTools”