MuLab 10.0.85

[MuTools]

MuLab App M10.0.13 beta for Windows 64 bit is available on https://www.mutools.com/mulab/app/lates ... /beta.html

What's changed:

• Upon drop audio file the popup button list showed a wrong button for the audio streams. Fixed.
• Upon replacing a module which also had an "Open Editor" front panel button, that button now disappeared, in contrast to M9. Fixed.
• New "Window Border Size" preference. By default windows now have a bit bigger border.
• If a window is not resizable, dragging the border now will move the window.
• When dragging a window's position or border, there could be an uncomfortable lag between the drag starting point and the current mouse position. Fixed.
• Choose module for rack slot -> Add new plugin -> cancel => caused a crash. Fixed.
• Using the [+] rack slot button below the last slot did not work as expected. Fixed.
• Dropping a MUX preset from the browser to an empty rack slot was not yet undoable. Now it is.
• Dropping a MUX preset from the browser to a rack slot did not yet adapt the rack slot ins-outs. Fixed.
• Previously it was not allowed to drop a rack into a rack slot. Now it is.
• Drop project sample from project browser to composer paused playback during the clip type dialog. Fixed.
• Other small improvements.

[FabBad]

When dragging a window's position or border, there could be an uncomfortable lag between the drag starting point and the current mouse position. Fixed.

THIS! finally fixed! I reported this a couple of years ago.

[Taron]

Inactivate really is a verb in English. (Edit: First attested in 1906.) It's the same as deactivate. Whichever you prefer is fine.

Make Work.
Make Not Work.

Though remotely, it reminds me of the joy to read Java code: if disable is true, don't do it. Seems trivial by itself, but in the midst of any length of code...

[liquidsound]

Now I can insert, for example SerumFX, in a slot after an Instrument and the Midi is able to get to SerumFX (for Envelops-Lfo to work).
I tried this with v9 but I had to go modular in order to make it work (or perhaps I was doing it wrong?).

Great!

[syntonica]

Inactivate really is a verb in English. (Edit: First attested in 1906.) It's the same as deactivate. Whichever you prefer is fine.

Make Work.
Make Not Work.

Though remotely, it reminds me of the joy to read Java code: if disable is true, don't do it. Seems trivial by itself, but in the midst of any length of code...

That's backwards.

if (thingEnabled) { doTheThing }

[Taron]

Inactivate really is a verb in English. (Edit: First attested in 1906.) It's the same as deactivate. Whichever you prefer is fine.

Make Work.
Make Not Work.

Though remotely, it reminds me of the joy to read Java code: if disable is true, don't do it. Seems trivial by itself, but in the midst of any length of code...

That's backwards.

if (thingEnabled) { doTheThing }

Exactly! But the APIs of Java love using a field called "disabled". Drove me nuts early on.

[syntonica]

Inactivate really is a verb in English. (Edit: First attested in 1906.) It's the same as deactivate. Whichever you prefer is fine.

Make Work.
Make Not Work.

Though remotely, it reminds me of the joy to read Java code: if disable is true, don't do it. Seems trivial by itself, but in the midst of any length of code...

That's backwards.

if (thingEnabled) { doTheThing }

Exactly! But the APIs of Java love using a field called "disabled". Drove me nuts early on.

Everything about Java APIs drives me nuts. Zero consistency.

[Taron]

Inactivate really is a verb in English. (Edit: First attested in 1906.) It's the same as deactivate. Whichever you prefer is fine.

Make Work.
Make Not Work.

Though remotely, it reminds me of the joy to read Java code: if disable is true, don't do it. Seems trivial by itself, but in the midst of any length of code...

That's backwards.

if (thingEnabled) { doTheThing }

Exactly! But the APIs of Java love using a field called "disabled". Drove me nuts early on.

Everything about Java APIs drives me nuts. Zero consistency.

That could become a massive tangent here. Better we leave it at that, hahaha, before we start listing our grievances about it.

[MuTools]

MuLab App M10.0.14 beta for Windows 64 bit is available on https://www.mutools.com/mulab/app/lates ... /beta.html

What's changed:

• EQ/Filter Bank: By default the editor used no folding of the top controls. Now it uses the "Fold MUX Front Panel Top Controls" preference as default.
• Dragging a window by its title bar now is not limited to the top of the screen(s) anymore since now a better method is used i.e. a minimum border area to avoid that a window is accidentally fully dragged off screen(s) thereby making it inaccessible.
• When quitting MuLab while there still was a module slot with a plugin on the clipboard, this caused a crash. Fixed.
• When you replaced anything in a rack slot with a send, and then undo that action, the arrow on the original slot greyed out. Fixed.
• Drag-dropping a rack between different rack desks / rack levels did not work correctly. Fixed.
• Context menu for module slot was missing. Fixed.
• MUX Front Panels: In edit mode the window was not resizable anymore. Fixed.
• Other small improvements + bug fixes.

[FabBad]

What happened to the right click on edges of the program? It was useful to take the usual buttons on any place on the program borders. Also, it used to drag on right click right?

[MuTools]

It will return.

[MuTools]

MuLab App M10.0.15 beta for Windows 64 bit is available on https://www.mutools.com/mulab/app/lates ... /beta.html

What's changed:

• Right-click window border now works as before again.
• Loading a preset now is an undoable action.

[MuTools]

MuLab App M10.0.16 beta for Windows 64 bit is available on https://www.mutools.com/mulab/app/lates ... /beta.html

What's changed:

• Important fix for a recent new bug which could result in modules not playing until the green power button was toggled off-on. Also previewing from the browser was affected. As this was a very annoying / confusing bug that's why this M10 beta update is published earlier than planned, for making this fix available.
• New preference "Grouped Undo For Load Presets Max Delta Seconds": (not sure if that's the best description?)
  When browsing thru presets in search for a good match and the time between 2 presets is max. this preference, this will result in only a single undo step so to avoid redundant undo steps and related RAM usage (eg. by used samples).
  In other words: If you step thru 20 presets in search for a good match and there only is max a specified amount of seconds between those browsed presets, this will only use a single common undo step. You can also switch this feature off.

By the way: As you can see this new preference is in the Undo-Redo preference group. Many more preferences will be grouped together in the coming updates. It will not always be easy to decide in which group a specific preference belongs, but grouping preferences will surely make it more comfortable, as already have been suggested by users before.

[PelletProject]

Good to see grouped preferences being explored at last!

IMO it would be a lot more ergonomic if preferences were sorted with a handful of tabs you could switch between, with some subgroups to divide within them if it's necessary to be more specific, as opposed to a drop-down approach. Drop-down I think still runs the risk of cluttering further with all tabs open and still having to scroll in some cases.

I made a few quick mockups in MUX. Hopefully they convey what I mean. Here's one with tabs on top...


And another with tabs to the side.


I'm aware this is all subjective anyway; ironic how the Preferences tab could be up to preference...

[robert_p]

And another with tabs to the side.

I like tabs on the side.