MuLab 9.0.59 App + Plugin

[Karlatin]

Not related to his other issues but I am seeing the issue which Dakkra sees of MuLab not closing itself out after program close.

Each time I enter MuLab and then exit, Windows Task Manager shows a MuLab process still running, of about 340 MB in size, though I understand that this will vary from his project sizes to mine. If I repeat the opening and then closing of MuLab several times, it will stack unclosed processes so that if I did this six times, my RAM would be about 2 GB 'overstuffed'.

The processes are kill-able, though; I remember a long-standing bug with Bitwig where the zombie processes could only be killed with a reboot, so this here's a plus

Win7 64bit, SP1, non write-protected path for MuLab.


(NEW - Log files sent via email)

[MuTools]

Thx for your feedback & log files Karlatin!

[MuTools]

MuLab App 9.0.51 is available in https://www.mutools.com/mulab/app/latest-binary

What's changed: When quiting MuLab M9.0.48, it could hang while shutting down. Fixed.

MuLab Plugin does not have this bug so no need for a quick fix for MuLab Plugin.

Thanks Dakkra & Karlatin for spotting this bug so fast and for sending the log files which helped to narrow this down.

[humanboeing]

Drag&dropping mucomposer preset from browser to rack does not produce a composer module as one would expect.
Multi-selection in the browser does not work, for example: select several samples from the project and delete them, only the last one is prompted to be deleted instead of all selected.

[MuTools]

Thanks for your feedback, taken notes on the wishlist.

[FabBad]

Bugs related to Audio sequence

1. End event at audio end extend to infinite
2. Empty events results in overcover the drawn waveform on the track

3. I think is related to the other post but this time is when i open a project with empty audio sequence and when add samples, the waveforms draws are not reflected on the track

[MuTools]

Bugs related to Audio sequence
1. End event at audio end extend to infinite

Will be fixed in the next update.

2. Empty events results in overcover the drawn waveform on the track

Will be fixed in the next update.

3. I think is related to the other post but this time is when i open a project with empty audio sequence and when add samples, the waveforms draws are not reflected on the track

Please elaborate by listing the precise steps to repeat this.
Alternatively, wait for the next update and check if the issue is still there as indeed maybe it's related to one of the other issues that will be fixed.

Thx for reporting these bugs.

[FabBad]

Please elaborate by listing the precise steps to repeat this.
Alternatively, wait for the next update and check if the issue is still there as indeed maybe it's related to one of the other issues that will be fixed.

I try to reproduce with no look but i have the template that has the draw problem, so the steps are:

1. open the audio sequence and load any sample on it
2. now you can see that is not drawing on the main arragement.
-------------
2_I'm curious about why the projects don't store the windows possition, it always open maximized.


*A side question, have you checked the mail i sent?

I really apreciate your work Jo

[humanboeing]

Copying one track via a shortcut and then pasting it on top of another gets completely rid of the old track (and connected rack) with no undo. Is this intended? I almost lost progress by accidentaly doing it.

[MuTools]

What do you mean with "Copy track" ?

[humanboeing]

What do you mean with "Copy track" ?

Select a track, hold mouse cursor on top of it, use a copy shortcut (mine is ctrl+c)

[hope4ever]

vst2 will be gone sooner or later
every host should support vst3 asap

Steinberg's attempt to kill off vst2 is abominable for a variety of reasons:
1. New plugin Devs are forced to use vst3, which I understand is a botched affair, bad for developers, and unfriendly to end users.
2. Existing DAWs (like mulab) pretty much forced to adopt vst3 or be incompatible with newer plugins.
3. SB attempted to terminate existing vst2 licenses for Devs adopting vst3 (which they might yet try again). This would mean DAW developers no longer being allowed to support vst2, killing off a lot of excellent existing vst2 plugins which may not be updated to vst3 for various reasons, including their devs no longer operating. Most unfriendly towards developers, end users and producers. vst2 plugins are far more ubiquitous than vst3 or any other format.
Steinberg must have their own (warped) reasons for doing this, but I don't see how it makes sense for anyone else!
If Vst3 format was any good at all it would sell on its own merit, and naturally supplant the earlier format. Folks would be eager to upgrade to the newer format, and there would be no need at all to try to suppress vst2. Unfortunately, to the end user, like so many so called 'upgrades' these days, it feels like more has been taken away than added.
I sincerely hope the CLAP initiative works out and supplants vst2 and vst3. Bottom line though is I want to be able to continue using my old vst2 plugins while still being able to play with the new stuff from both existing and new developers. I don't want to have to worry about format wars, or policies which exclude me from using either great new plugins or favourite older plugins.

Agree.
Especially to the part in bold text.

[MuTools]

What do you mean with "Copy track" ?

Select a track, hold mouse cursor on top of it, use a copy shortcut (mine is ctrl+c)

Note that this will copy the target rack/module/plugin for that track as copying a track itself is not supported. That's because in the case you described shortcut keys first goto the track, and if the track doesn't recognize the shortcut key (which is the case here) then the target module will check if it recognizes the shortcut key.

So i wonder where you pasted that copied rack/module/plugin?

[humanboeing]

So i wonder where you pasted that copied rack/module/plugin?

I pasted it on another track, which had another rack as a target, although all of this was done by accident.

Shouldn't it be classified as a 'non-undoable delete' and taken into account for the preference? The rack is gone after the action.

[MuTools]

I understand your point and agree that there should be a confirmation alert, until the future version where this action becomes undoable.