MuLab 7.1.30

[ApBTranCer]

Hi jo,

Great to see the vst "white window" bug disappear! Now vst windows are covering "focused" programs that aren't mulab, but I am able to exit these windows, so not a huge problem.

You can see in this attachment that my focus is on Safari, but the vst is still in the front.

I'm happy to hear that Mac Mux might be a thing!

Cheers!
Austin

[MuTools]

Thanks for your feedback Austin.

[syntonica]

Oddly, I just discovered Tassman is now working... Not sure if it just needed to be rescanned or the latest version of MuLab now allows the bridge to run, but by going to 64-bit, the only thing I have lost and still need to replace are my very old reFX plugs that barely made it out of PPC and into Intel.

As a side note, the 32-bit version runs on Sierra, but VSTs are white windowing right and left now! Now if I can only get every plug-in maker to recompile against the latest Juce lib... I think there's a hack you can add in Mulab, but really, you shouldn't have to...

Anyways, I'm soldiering on with 64-bit...

Also, I had a small test project, curiously called Test, that got destroyed somehow. Mulab refused to open it and opened the default New project instead. No big deal--1 looped bar, but I'm not sure where the corruption began and who started it. I will back up all my projects far more religiously for a while in case it happens to something important. I will try and get proper logs and documentation in case it happens again. You only made changes to the graphics subsystem, correct?

Not sure why I never went into software testing professionally. My talent is I can generally crash any program within 5 minutes just by fiddling about.

Jo, I hope you are well and still locked in your secret lab in the base of the dormant volcano diligently making improvements.

[MuTools]

As a side note, the 32-bit version runs on Sierra, but VSTs are white windowing right and left now! Now if I can only get every plug-in maker to recompile against the latest Juce lib... I think there's a hack you can add in Mulab, but really, you shouldn't have to...

Indeed it would be a waste of dev time. Apple Carbon is virtually dead.

Anyways, I'm soldiering on with 64-bit...

Good choice. On Mac there is little choice left.

You only made changes to the graphics subsystem, correct?

Yes, more or less. Not easy to answer this question accurately. Anyway, there should be no reason for issues wrt opening project files. If you're sure there is such issue pls give me a step by step how to repeat it, preferably starting from a New project.

Not sure why I never went into software testing professionally. My talent is I can generally crash any program within 5 minutes just by fiddling about.

Can you crash M7.1.9? If yes, pls give me the step by step so i can repeat it.

Jo, I hope you are well and still locked in your secret lab in the base of the dormant volcano diligently making improvements.

I'm fine, thank you, and i hope of myself i'm not locked
I'm currently working on an 'extra' for the M7.1 update. It's a new module. More news coming soon.

[syntonica]

Indeed it would be a waste of dev time. Apple Carbon is virtually dead.

Someone tell that to Carbon! Apple just needs to drop the Framework and be done with it, like they did with Rosetta. And they should have added a drop dead to it, such as when they released 10.9, they should have deprecated it and stated it will live through the end of 10.10. Instead, they just wishy-washy their support.

Yes, more or less. Not easy to answer this question accurately.

Completely understood!

Can you crash M7.1.9? If yes, pls give me the step by step so i can repeat it.

The only time I have crashed is when repeatedly replacing an effect with different VSTs to audition them. Knowing how goofy most of those different VSTs are, I'm surprised MuLab stands up as well as it does! The option to sandbox a plugin would be cool, but not a real priority.

[MuTools]

The only time I have crashed is when repeatedly replacing an effect with different VSTs to audition them. Knowing how goofy most of those different VSTs are, I'm surprised MuLab stands up as well as it does! The option to sandbox a plugin would be cool, but not a real priority.

Sandboxing is not planned. My recommended solution to deal with unstable VSTs is: Avoid them. Replace them with stable VSTs. And even then this golden rule in software land: Regularly save. (besides MuLab's autosave)

[syntonica]

Figured out how I corrupted my Test project.

1. Open New project.
2. Insert one VST demo of the type that does NOT save settings. (I am testing Valhalla Room.)
3. Save project.
4. Reopen project, get Could not Create Some Module(s), then Couldn't open project.

This does not happen with 32-bit.

Of course, I use these tests to try out different VSTs, demos and otherwise, so I don't put my important projects at risk.

[antoniaz]

Figured out how I corrupted my Test project.

1. Open New project.
2. Insert one VST demo of the type that does NOT save settings. (I am testing Valhalla Room.)
3. Save project.
4. Reopen project, get Could not Create Some Module(s), then Couldn't open project.

This does not happen with 32-bit.

Of course, I use these tests to try out different VSTs, demos and otherwise, so I don't put my important projects at risk.

It's exactly one of the scenarios I also reported before in this thread.
Have you checked what happens by replacing the critical project with a new empty one and then reopening the critical one again without quitting MuLab ?
In such case I don't have issues, while not acceptable in general anyway.

[syntonica]

I just blew up another project, this time established with no demo VSTs. Saving often doesn't help since it's the save that's killing it! No errors on saving, but getting "MpuStp [1050] couldn't load plug rack" when trying to reopen.

I've gotta go back to Mavericks and 32-bit if I can't work.

[syntonica]

Figured out how I corrupted my Test project.

1. Open New project.
2. Insert one VST demo of the type that does NOT save settings. (I am testing Valhalla Room.)
3. Save project.
4. Reopen project, get Could not Create Some Module(s), then Couldn't open project.

This does not happen with 32-bit.

Of course, I use these tests to try out different VSTs, demos and otherwise, so I don't put my important projects at risk.

It's exactly one of the scenarios I also reported before in this thread.
Have you checked what happens by replacing the critical project with a new empty one and then reopening the critical one again without quitting MuLab ?
In such case I don't have issues, while not acceptable in general anyway.

I didn't realize this was the same issue that you reported. I just got nailed again, this time working on a mix. Fortunately, it's just a set of stems that I can drop in and add some a verb or two to get back to the basic mix. I just replaced the project files with my back-up copy, otherwise, I would give what you suggested a try.

My feeling is some object is not being disposed of properly when deleted as I did add a VSTi to a mixer and it came up with a (2) after it, even though it was the only vst inserted. When saving, this phantom vst is gumming up the works. I will work on this project again tonight and see what happens. The Unmixable Project v.9.0. Guess I will have to get brutal with the EQ.

[MuTools]

I can repeat the save-reopen issue now. Researching it.

[syntonica]

Have you checked what happens by replacing the critical project with a new empty one and then reopening the critical one again without quitting MuLab ?

I tried that. I only got my MIDI clip back. No VSTs load in the problem rack and the audio out is blown. The Master outputs to No Audio Output.

As a side note, I restored back to Mavericks and now I can work in the 32-bit version and test the 64-bit when an update comes. While Sierra was okay, I noticed it had a couple of wee buggies too that were annoying. My favorite was moving a VST window to the side and leaving the contents behind! I couldn't repeat the behavior, though.

[MuTools]

Found & fixed that save-open bug. Antoniaz, Syntonica, i'm sorry i could not immediately recognize this bug based on your reports, but thing is that this bug only occurred in very specific conditions and even then not always. And on top of that there also is ambiguous behaviour of the XCode compiler which made it extra difficult to track this bug. Anyway, the very reason is in the MuLab code itself and it's fixed in the next update which will be available soon. Thanks for reporting this!

[antoniaz]

Found & fixed that save-open bug. Antoniaz, Syntonica, i'm sorry i could not immediately recognize this bug based on your reports, but thing is that this bug only occurred in very specific conditions and even then not always. And on top of that there also is ambiguous behaviour of the XCode compiler which made it extra difficult to track this bug. Anyway, the very reason is in the MuLab code itself and it's fixed in the next update which will be available soon. Thanks for reporting this!

Great ! Looking forward for the fix update...

[LYTZ]

OSX 64bit... Now that's some news here, very nice...


Went on to check the last versions out, all looking good so far as well,
but what I noticed is a severe performance dropdown between 7.1.9 GUI performance
and prior Versions (i.e. 7.0.47) in a quite linear fashion.

(i.e. draggin selections, moving stuff around and things of that nature have quite a delay to it.
It looks like a severe frame rate dropdown or what you get when the app is at it's CPU limits for example.)

This is **not** the case with 7.0.47 for example. The OSX "WindowsServer" that is used by MuTools 7.1.9
is using a lot of CPU by the way. Way more than Mulab itself, making it the number one Process on the activity monitor.

7.1.7 is somewhere in the middle. The OSX WindowsServer is not eating up that much CPU as in 7.1.9
(WindowsServer is a couple of processes behind Mulab, whereas with 7.1.9 the Server is No.1 on the whole system)

So 7.1.7 is a bit better than 7.1.9 but certainly by far not that snappy like 7.0.47.

I don't know what's going on here, but maybe this helps already.

By the way, I am still on OSX 10.10.5
and I tested this on all above versions with clean downloads and empty songs in stop mode... (not running)

Best,
tL.