MuLab 7.1.30

[Zexila]

But why would you need it?

Because I'm actually only using 32 bit plugins and not planning to go 64 bit at all, even on Windows, really don't have any reasons for that whatsoever, but that's me, majority of Mac audio users are 64 bit and 10.9+, so it doesn't mater anyways.

[syntonica]

Just tried .20. The vst glitchiness I was hearing is now gone. And it appears this version is just a tad less efficient than .15 by about 2% on a 55% CPU load, so really negligible. But it still performs better than the 32-bit!

Thanks once again for all your hard work, Jo!

[syntonica]

But why would you need it?

Because I'm actually only using 32 bit plugins and not planning to go 64 bit at all, even on Windows, really don't have any reasons for that whatsoever, but that's me, majority of Mac audio users are 64 bit and 10.9+, so it doesn't mater anyways.

Still on Snow Leopard? I would still be there too if I could. It seems to be the perfect spot for OSX, complete with Rosetta to run all the old stuff. Nothing Apple had added since has excited me, either user-wise or programming-wise. I just want to be able to use the really fast CPUs and Gfx cards, though, but Apple keeps piling more crap on to make it all run slower anyways.

Mavericks is my next favorite, but it looks like Sierra might be okay, as well, despite Apple hiding more and more stuff not just under the hood, but behind the engine where it's impossible to get to!

Unless you're running multiple instances of Kontact with multi GB samples, there's really no other reason I know of to go 32-bit if you don't have to.

That said, most plugs now come in 64-bit versions now, so you may want to squirrel them away too. Just in case.

[Zexila]

Still on Snow Leopard?

Yeah, think that's the last one for me, actually when I really think about it, would probably just use MuLab/or any other DAW on Windows anyways, if I of course pull the trigger and leave the Logic behind (got spare desktop machine collecting dust), so I guess when I really think about it, 32 bit OS X thing wouldn't be my issue at all, would still rock entirely 32 bit setup on Windows tho, no Kontakt and enough of 32 bit only plugins.

[syntonica]

Last Logic I used was 6, back when it was still Emagic. I got 7, but Apple had pretty much ruined it for me. 8 was even worse. I want to try Logic X, especially now that Alchemy has been added in, but don't want to waste $200 on something I will probably hate.

Besides, Mulab pretty much covers everything I need, other than one or two things on my wish list.

[MuTools]

Some more clarifying info:

In fact there could be 2 different 32 bit versions for Mac: a Carbon based one and a Cocoa based one.
The Carbon based one is what MuLab was up to M7.0.47. The problem with that approach is that Carbon is deprecated by Apple and more and more incompatibility issues were popping up especially wrt VST plugins. So that's why it was time to move to Cocoa. Also because i wanted to provide a 64 bit version of MuLab for Mac which is not possible with Carbon as the Carbon framework only exists in 32 bit. So the Carbon based 32 bit version stops here indeed. I'll keep the M7.0.47 32 bit Carbon version in the legacy collection though.
So the only option to be evaluated is making a 32 bit Cocoa version. But i think that makes little sense as many / most VST plugins won't show up their editor, as explained in an earlier post. So yes i think it's RIP MuLab 32 bit on Mac. And that's a consequence of Apple's choices, it's not my favorite own choice. But then i think moving to Mac 64 bit is ok, it gets you more up to date. Unless you still have a 32 bit Mac of course. But does a 32 bit Mac (=an older Mac) still has enough CPU power for todays DAW works? Isn't it a good time to step up to a new(er) (refurbished) Mac?

[Zexila]

You got the point really, even I wouldn't use 32 bit MuLab on a Mac, so yeah, pretty much there's no real issue here.

Last Logic I used was 6, back when it was still Emagic. I got 7, but Apple had pretty much ruined it for me. 8 was even worse. I want to try Logic X, especially now that Alchemy has been added in, but don't want to waste $200 on something I will probably hate.

If you disliked previous ones, you will definitely X too, know I do, being really into 8/9.

Besides, Mulab pretty much covers everything I need, other than one or two things on my wish list.

Yeah, MuLab is almost "there", but I'm afraid mine few things will take a while to come, so for now it's still not there for me, but we will see, who knows what tomorrow might bring.

[MuTools]

There is a new MuLab 7.1.21 for Mac 64 bit: http://www.mutools.com/galaxa/

How to install: Replace the current M7.1.x MuLab.app file with this newest version.

What's changed:

* Added extra protection wrt. entering invalid parameter values. (bis)

* As reported by several of you, M7.0.20 took a bit more cpu than M7.1.15.
I replied i could not see a reason for that and the difference was not very big so after all the hard work i first wanted to leave it like that. But ok i spent another bunch of hours on narrowing down where the difference comes from and i found the reason, which is another OSX quirk. And the most strange thing is that this quirk influences the audio processing, which i don't understand as it's about a Cocoa UI framework aspect. Well, i won't loose more time by investigating the deeper tech reason of that (would have to dive into Cocoa, maybe Darwin etc), but i did tweak the MU code a bit so to bypass that OSX quirk and yes we're back on M7.1.15 speed, but with all the improvements of M7.1.20 of course. Now lets cross fingers that things stay good as they are now and won't be broken by next OSX updates.

If there are any other issues, pls let me know. Thx.

[antoniaz]

There is a new MuLab 7.1.21 for Mac 64 bit: http://www.mutools.com/galaxa/

How to install: Replace the current M7.1.x MuLab.app file with this newest version.

What's changed:

* Added extra protection wrt. entering invalid parameter values. (bis)

* As reported by several of you, M7.0.20 took a bit more cpu than M7.1.15.
I replied i could not see a reason for that and the difference was not very big so after all the hard work i first wanted to leave it like that. But ok i spent another bunch of hours on narrowing down where the difference comes from and i found the reason, which is another OSX quirk. And the most strange thing is that this quirk influences the audio processing, which i don't understand as it's about a Cocoa UI framework aspect. Well, i won't loose more time by investigating the deeper tech reason of that (would have to dive into Cocoa, maybe Darwin etc), but i did tweak the MU code a bit so to bypass that OSX quirk and yes we're back on M7.1.15 speed, but with all the improvements of M7.1.20 of course. Now lets cross fingers that things stay good as they are now and won't be broken by next OSX updates.

If there are any other issues, pls let me know. Thx.

Just tried 7.1.21 on macOS Sierra and found a GUI issue with MuLab main window: it can be now moved up under the Mac system menubar so that it become impossible to move, resize or close the window through the top titlebar buttons. If I remember well, previous MuLab versions correctly prevented this case.

[MuTools]

Iirc it was the same in M7.0. I've taken a note on the wishlist about trying to avoid that case. For now: Try to avoid it from user side and if it happens accidentally you can always right-click the window border -> window context menu -> Move to Top Left. (or alt+drag the window border)

[antoniaz]

Iirc it was the same in M7.0. I've taken a note on the wishlist about trying to avoid that case. For now: Try to avoid it from user side and if it happens accidentally you can always right-click the window border -> window context menu -> Move to Top Left. (or alt+drag the window border)

Ok, please also take into account that this can happen also to other windows such as plugin wrappers, etc.
For the time being, thanks for the hint on "Move to Top Left" that at least allows to go on.

[syntonica]

Iirc it was the same in M7.0. I've taken a note on the wishlist about trying to avoid that case. For now: Try to avoid it from user side and if it happens accidentally you can always right-click the window border -> window context menu -> Move to Top Left. (or alt+drag the window border)

I take it that these are not standard Cocoa window wrappers that get the free "do not enter the menu bar." I haven't noticed, but are they stopped automatically at the top? Of so, maybe you can have an option on Mac to hide the menu bar? Since Mulab doesn't have Mac menus anyways.

[MuTools]

I've put a note on the wishlist about that possible menu bar issue and will evaluate it later. I need to switch back to working on audio and music aspects, these Mac works have been very expensive already, dev-time wise. Hope you understand i need to balance things a bit, Windows users (=75% of the users) are looking forward to updates too. Anyway pls do keep reporting things and i'll evaluate whether it will be handled in this M7.1 dev cycle or put on the wishlist for later evaluation. Thanks again for all your feedback on this very important MuLab for Mac transition! I hope M7.1.21 can be regarded as a very good Mac version, on all OSX versions, and better than M7.0.47. Is it?

[Michael L]

Yes! It is much better in many ways. This huge update makes it possible for us to continue using MuLab, in new macOS versions, and with 64-bit plugins. It solves a variety of UI issues, gives us 64-bit advantages, and (thanks to your world-class responsiveness to issues) continues the MuLab tradition of stability and great sound. Thank you very much for investing so much time to make all of this possible for we Mac users!

[syntonica]

(or alt+drag the window border)

I so didn't know about this. Forget about fixing the menu bar issue--this makes me really, really happy!

Now go make some new stuff that benefits All the Users!