MuLab 10.1.25

[FabBad]

Now, there's no crash but the ASIO stop working, direct sound works though.
Doing the same procedure as before.

[MuTools]

Can't repeat it.
Odd as MuLab 10.1 has no Direct Sound, only MME and ASIO.
Anyway, please quit MuLab and restart.
Then repeat the issue in as few steps as possible.
Then goto MuLab menu -> Tools -> Keep Log and share that most recent log file. (via this forum or via email)

[FabBad]

OK, my bad. it works fine, sorry.

[jd88]

Just installed the latest update of Mulab on my Mac (M1, 15.7.1) and unfortunately came across an issue which I also noticed in the previous Mulab. Whenever I add the reason rack plugin, I can work without errors within it. But there is something wrong with the UI after I close the floating window just once and then reopen it.

Please try this:
* MuLab menu -> Plugin Manager
* Select that plugin
* In the properties pane at the right, enable "Always Reset Editor Window"

Does that make a difference?

Here MuLab 10.1.20 (OSX up to 14.x) No different

(checking 10.1.22 later. I need to test an important BETA (major UD) right now)

[jd88]

deleted

[ApexSoundMusic]

Just installed the latest update of Mulab on my Mac (M1, 15.7.1) and unfortunately came across an issue which I also noticed in the previous Mulab. Whenever I add the reason rack plugin, I can work without errors within it. But there is something wrong with the UI after I close the floating window just once and then reopen it.

Please try this:
* MuLab menu -> Plugin Manager
* Select that plugin
* In the properties pane at the right, enable "Always Reset Editor Window"

Does that make a difference?

No unfortunately not. Still the same issue.

[MuTools]

A pity. I'm afraid i can't do more about this atm. Maybe the plug dev sees a reason?

Does that plug have a CLAP version? If yes try that one.

[MuTools]

MuLab App M10.1.23 is available:
https://www.mutools.com/mulab/app/lates ... /beta.html

MuLab Plugin M10.1.23 is available:
https://www.mutools.com/mulab/plugin/la ... /beta.html

What's changed:

• Mixer strip: When receiving a pure mono signal then while the gain / pan / stereo width was changed there could be audible artifacts. Fixed.
• Other small improvements.

[ApexSoundMusic]

Well I can try out to reach Reason, see if that yields any results..
Hopefully it gets resolved one way or another, because I use the Reason Rack plugin a lot! Being able to use Mulab and that one together is the killer combination for me. Unfortunately just not yet now. In the meantime I also logged a support ticket at Reason.

[MuTools]

Well I can try out to reach Reason, see if that yields any results..
Hopefully it gets resolved one way or another, because I use the Reason Rack plugin a lot! Being able to use Mulab and that one together is the killer combination for me. Unfortunately just not yet now. In the meantime I also logged a support ticket at Reason.

Please do this short test to create a MuLab log file:

* Restart MuLab 10.1.23.
* Insert Reason Rack and open-close its editor until the issue has repeated itself.
* Goto MuLab menu -> Tools -> Copy Log and paste the log data in a reply here or in an email to

That may help in narrowing it down.

[jd88]

(Now I'm mentioning this in this forum too):

I have to say something:

Here in this forum, you're childishly ignored by DAW developers after a certain point (e.g., when you honestly answer a question from the DAW's creator, for example, regarding the automation list) or drawn into petty personal discussions (e.g., about parameters, etc.). Otherwise, (in this case): WE could help. That was the initial idea. But whatever. This has now been resolved.

It's a shame, but it's no wonder that the DAW isn't improving in the rankings. A great idea like MuLab just isn't catching on.

- - - - -

Objectively:

1. The problem with VST plugins (!) like Reason has been known for a long time. Very few other DAWs also had this issue initially, especially in the first version of Reason VST. However, this is something you only know if you think outside the box and, as a developer, actually contact the manufacturers yourself.

The plugin now definitely works in ALL (!) DAWs, especially major ones.

Reason Studios, by the way, provides absolutely excellent support for DAW developers.

-
I don't even dare mention the MuLab problem with VSTs like "ReNoise Redux" (which definitely works in every other DAW!! and there's a demo available for download).

- - - - -

2. It's inexplicable to me why MuLab can't resolve fundamental timing issues (including controllers, etc., which are sometimes shifted without being thinned out) and the sync problem when starting sync in recording mode.

This, too, is really easy to fix.

And this is clearly a MuLab bug.



``` Here's a tip:

This problem, along with many others, including those related to the modular area (since the instructions are truly inadequate), has been discussed in other forums, and I've already posted this umpteenth workaround that's repeatedly needed for MuLab:

If you increase the count-in to two bars, the record sync start works.

With this tip, fixing the bug should be easy, right?

- - - - -

It's becoming increasingly clear that while MuLab support is often quick, it's somewhat idiosyncratic. They jump around wildly when trying to fix things. This is certainly one way to do it, but it has happened often enough now that a fix has created another (sometimes predictable) problem. (See the flickering display error, or, for example, the MuLab plugin display issue, and various problems with closing windows.)

For example, I still don't understand why this orange background, which originates from MuLab (e.g., the flickering... and you can also see it with the Reason VST problem), isn't simply replaced with a neutral background. Then it wouldn't be so noticeable. AND: Yes, here's another tip: Instead of just delaying the loading/closing of plugins, etc., most other DAWs handle it with a neutral background. Clearly visible in Reaper, for example.

It's astonishing that such serious bugs in one's own DAW went unnoticed for almost 10 years (e.g., OSC, etc.).


---

The MuLab VST plugin will unfortunately become increasingly obsolete if it isn't released as a VST3/AU soon. There's no hope for MPE at all. (According to a survey about what users are missing in MuLab)

It would do "MuTools/MuLab!!" a world of good if feature priorities finally shifted in the right direction.

-----

Honestly: It's such a shame that this fantastic (MuLab) idea is currently receiving so little attention that such a great foundation/idea deserves and is constantly being overtaken by other, much newer programs.

For the user, it's irrelevant whether a DAW is created/maintained/developed by one or more people. And this has little to do with it anyway.

What's important is that it works.

In conclusion:

I would be very happy if the small, easily fixable bugs could finally be resolved in the near future.

(As allways "GOOGLE TRANSLATE"!)

[MuTools]

Here in this forum, you're childishly ignored by DAW developers after a certain point (e.g., when you honestly answer a question from the DAW's creator, for example, regarding the automation list)

I don't know what you mean.
Which DAW developer?
Which question about automation list?
Please link to the conversation.

or drawn into petty personal discussions (e.g., about parameters, etc.).

Sounds too vague for me.
Please add concrete detail.

2. It's inexplicable to me why MuLab can't resolve fundamental timing issues (including controllers, etc., which are sometimes shifted without being thinned out)

I don't know what you mean.
Yesterday you also posted a long mail complaining about an issue with CC recording timing, but then you deleted all of that mail.

Anyway, i double-checked recording CC from a MIDI controller using M10.1.23 and did not see anything wrong with the recorded events. So please provide a clear and concrete step by step.

and the sync problem when starting sync in recording mode.

Did not yet find the time to research that plugin related report.

It's becoming increasingly clear that while MuLab support is often quick, it's somewhat idiosyncratic. They jump around wildly when trying to fix things. This is certainly one way to do it, but it has happened often enough now that a fix has created another (sometimes predictable) problem.

I can only say that i always go for solid, future-oriented coding solutions.
It's a fast world and i'm a sole developer and have a huge workload and yes i admit that recently there has been quite some (re)bug fixing due to the need to increase coding speed. But 1) i hope you appreciate the fixes and 2) often these new bugs are a consequence of me being hard coding forward. If you want to help MuLab grow, then user testing and reporting is much appreciated. There is no other option atm.

(See the flickering display error, or, for example, the MuLab plugin display issue, and various problems with closing windows.)

I'm amazed you're again encountering a 'flickering window issue' on your Mac.
I remember you confirmed via email that this issue, which also happens in other software, and which did not happen on one of your other Macs with the very same MuLab, and which, imho, is caused by erratic changes in MacOS by Apple, was fixed by a workaround patch in MuLab 10.0.85.

For example, I still don't understand why this orange background, which originates from MuLab (e.g., the flickering... and you can also see it with the Reason VST problem), isn't simply replaced with a neutral background. Then it wouldn't be so noticeable.

The orange color is set by MuLab yes.
First, while we were emailing about this some months ago, i didn't realize where that specific color came from, but later i found the relevant coding line. At the time that coding line was written, many years ago, that orange color was intentionally chosen to be very notable because i assumed that it should never be visible to the user, and IF it would be visible then it would indicate an issue and so the orange was a good marker. But it indeed may be a better choice to use a more subtle color as MacOS is an erratic platform and so anything can happen when Apple decides to change the system and break compatibilities again, and again, and again...
In the next MuLab update the orange color will be replaced by dark gray.

It's astonishing that such serious bugs in one's own DAW went unnoticed for almost 10 years (e.g., OSC, etc.).

1) I think you exaggerate and also forget that several of these MacOS related issues are MacOS version dependent and sometimes a consequence of Apple changing things in a sudden, incompatible way. I'm not the only developer / user impacted by Apple's erraticness.
2) About your brief "OSC" reference: Note that an unfulfilled feature request is not "a bug".

The MuLab VST plugin will unfortunately become increasingly obsolete if it isn't released as a VST3/AU soon.

1) Upgrading MuLab Plugin to other plugin formats is (almost) at the top of the worklist. I'm fully aware of that priority.
2) Please rationalize your choice of the word "soon". On which concrete info are you basing yourself?

There's no hope for MPE at all.

Your words, not mine.

It would do "MuTools/MuLab!!" a world of good if feature priorities finally shifted in the right direction.

I think what MuLab needs most is more marketing power as the project has grown a bit big for 1 dev doing coding, documenting, tutorials, answering user questions and feedback, marketing, hyped videos, etc... Anyway, continuely doing my best.

What MuLab also needs is more users talking about it on social media, and share tracks made by it, videos, projects, presets etc...
A bigger and louder user base!

Honestly: It's such a shame that this fantastic (MuLab) idea is currently receiving so little attention that such a great foundation/idea deserves and is constantly being overtaken by other, much newer programs.

Thank you for your appreciation, support and constructive criticism

NB: If you would add lengthy replies, i may not be able to reply on it on short term, possibly only later, due to time management.

[syntonica]

No! Not the orange! I've been able to use screen shots of it to report bugs to plugin authors a couple of times. It makes the discrepancies VERY clear and easy to see what's going on. As you started, the users should never see it, but we do.

[sl23]

@jd88: I hear your frustration. There are things we all want added or fixed, but Jo is a lone developer that is unable to solve all things and keep to a quick schedule, it's just not possible. I myself want one fix and one request implemented. They've already been discussed and though disappointed, I understand the situation. It's such a shame and has actually pushed me back to using hardware more. I really do hope that MuTools can extend it's staff base one day and make quicker progress. Keep going Jo, I'm not criticising at all, it really is a shame you're having so much trouble expanding the business. But don't give up, it's still my only DAW and I wouldn't even consider anything else personally due to the ease of use MuLab offers.

[MuTools]

Well, one can focus on what is not yet implemented, that's human.
Let me rehighlight everything that has been implemented: https://www.mutools.com/mulab-mux-change-log.html

The main step in MuLab 9 was making the composer a module and making it all available as a plugin. Believe me that was heavy restructuring of the code. It pushed MuLab to a next level in modularity, with an eye on the future.

The main step in MuLab 10 was making the racks fully modular and at the same time improving the undo-redo system. Also this took fundamental code restructurings, again future oriented, chasing the dream.

And, sl23, you requested support for multiple plugins in a single plugin file. I would not have chosen that myself, didn't like that job, but i promised to add it and implemented it. So you got that. And that was a big job too, a partial rewrite of the plugin system.

All these recent steps needed serious code works. That's also why there were some new bugs that had to be killed here and there. But i think M10.1.23 already is a good usable version. No? Anyway please keep on reporting bugs if you notice them, they will get killed.
(taking abstraction of plugin issues, which may be on plug side, may be on host side, may be in between, the VST3 SDK is not strict and tight enough and causes implementation jitter, unfortunately; I have to be careful not to sink into that dangerous swamp)

Just saying all this to also emphasize the positive sides. It's not meant as a defensive reaction.
I do understand the frustration that things go slower than we all want.
There are several reasons for that, also in personal life, but i continue fighting and working on solutions and hopefully i'm taking the right choices and hopefully it will deliver us happiness