MU.LAB 2.0 PreRelease F

[MuTools]

MU.LAB 2.0 PreRelease F has been released.

This new version features finetuned behaviour regarding focussing targets and setting the MIDI Input Target.

In the main Edit menu there is an option "Use Automatic/Manual MIDI Input Target".

The first mode, the MIDI input always goes to the focussed target in the GUI.
So if you click a track with a target, and you click on that track, MIDI input goes to that target. Then if you click a rack's name, MIDI input goes to that rack.

In the second mode, MIDI input keeps the same target until you explicitly choose another target by using the track/part/plugin context menus.

MU.LAB defaults to "Use Automatic MIDI Input Target", which is very close to the original behaviour before the track targets came into play.

The "Use Manual MIDI Input Target" mode is very useful e.g. when one person is playing on the MIDI keyboard, while another person is doing edits in MU.LAB, as the edits in MU.LAB won't affect the MIDI keyboard target unless explicitly requested.

Note that i had to change some code for this so please test this new system out thoroughly so that MU.LAB 2.0 can soon be released as bug-free as possible.

MU.LAB 2.0 PreRelease F is available as a patch at:

OSX: http://www.mutools.com/mulab/mulab20-prf-patch-osx.zip
WIN: http://www.mutools.com/mulab/mulab20-prf-patch-win.zip

Drag & drop the new application in this zip package into your existing MU.LAB PreRelease E folder, then when your OS alerts about the existing version, choose Overwrite/Replace.

[MuTools]

A new version "PreRelease F2" is available at

OSX: http://www.mutools.com/mulab/mulab20-prf2-patch-osx.zip
WIN: http://www.mutools.com/mulab/mulab20-prf2-patch-win.zip

Again this is a patch update. So drag & drop the new application in this zip package into your existing MU.LAB PreRelease E/F folder, then when your OS alerts about the existing version, choose Overwrite/Replace.

This new version features finetuned behaviour where new recordings are placed.

Because in the previous version it could be that you recorded something playing plug X, but then the recording was placed on the focussed track even if that track was targetting plug Y, and so this resulted in an unexpected change of sound.

PreRelease F2 uses a more finetuned procedure to determine on which track a new recording is placed.

For the overview of all latest changes, you can always check:

http://www.mutools.com/mulab/changes.txt

[MuTools]

A new patch update "PreRelease F3" is available at

OSX: http://www.mutools.com/mulab/mulab20-prf3-patch-osx.zip
WIN: http://www.mutools.com/mulab/mulab20-prf3-patch-win.zip

If you have already installed PreRelease E or F, then just drag & drop this new application into your existing MU.LAB folder, then when your OS alerts about the existing version, choose Overwrite/Replace.

Also the complete packages on the MUTOOLS Downloads page are up to date.

What's changed:

The 'focussed track' subsystem has been removed as it was almost redundant in the context of the new recording algorithm of "PreRelease F2".

Less is more

Together with the removal of track focussing, the algorithm to define the destination track for a new recording has further been finetuned.

MU.LAB now always tries to put the new recording on the lowest track using the same target as the recording; If no place there, then a new track is created and inserted below the relevant track.

All these latest changes together should form a very easy and user-friendly system regarding the selection and recording of plugins.

The need for these late tunings were caused by the coming of the new track targets, which definitely is a very valuable new feature in version 2.0.

Apologies for any inconvenience this burst of updates may have caused.

For the overview of all latest changes, you can always check:
http://www.mutools.com/mulab/changes.txt

Cheers,

Jo

[pljones]

I'll try to get some recording done, then, to test things. I've had a bit of a play in the last couple of days and not hit anything odd yet.

[pljones]

Very quick play around with MIDI recording.

It's really comfortable.

Start a new MuSession with absolutely nothing in it. Pick a player and add it to a new rack. Hit record. Stop when you're done. Reposition to continue the recording. Hit record, stop. New recording on same track (as I positioned at the end of the old one). Reposition, record, stop. New track, same target, as I'd positioned to accompany the first two parts. OK, new player, new rack; reposition, record, stop - new track, starting after the end of everything else, as that's where I'd positioned (so even though a part could have been positioned on an existing track, it would have had the wrong track target).

[pljones]

Where in the docs does it tell me how to assign a MUX meta-parameter to a contained plugin's parameter?

[MuTools]

Start a new MuSession with absolutely nothing in it. Pick a player and add it to a new rack. Hit record. Stop when you're done. Reposition to continue the recording. Hit record, stop. New recording on same track (as I positioned at the end of the old one). Reposition, record, stop. New track, same target, as I'd positioned to accompany the first two parts. OK, new player, new rack; reposition, record, stop - new track, starting after the end of everything else, as that's where I'd positioned (so even though a part could have been positioned on an existing track, it would have had the wrong track target).

Just to make sure i'm with you: this is no bug report right?

[MuTools]

Where in the docs does it tell me how to assign a MUX meta-parameter to a contained plugin's parameter?

It may not be explicit in there.

For efficiency reasons, it's not the intention to describe every single feature in the docs, but rather describe the global guidelines of how MU.LAB works.

Based on the docs, it should be self-explanatory to right-click a meta-parameter to see what the context options are.

And it's also accessible via the "Options" menu.

[pljones]

I still can't work it out... Maybe I'm just doing it wrong.

When I right-click a knob, it has three entries: "Map MIDI Controller" (that's not what I want to do, really), "Rename Parameter" (nope), "Edit Parameter Map" (which brings up an empty list from which the only option is "Delete"). If I do choose "Map MIDI Controller", it just binds a MIDI controller to the knob, rather than the knob to an embedded plugin's parameters.

[Bonteburg]

I noticed that the mouse clicking behavior when accessing a part's context menu has improved dramatically!

Thought it was just my nervous index finger to begin with but sequences kept opening when I didn't want them too. It's totally gone now. Can you confirm this or am I seeing things?

Marco

[MuTools]

Cannot confirm, nothing has changed in that field.

What were you exactly seeing?

That a single-click opened the sequence-editor?

[MuTools]

MU.LAB 2.0 PreRelease F4 has been released and fixes a bug when changing the MIDI channel for a sequence part.

This new MU.LAB version is availabe on the MUTOOLS Downloads page.

If you already have installed PreRelease D, E or F, you can just copy the new application file into your current mulab folder, this way you can avoid a resetup.

[Bonteburg]

Cannot confirm, nothing has changed in that field.

What were you exactly seeing?

That a single-click opened the sequence-editor?

something similar - it would happen mostly when doing my special Bonteburg duplicate part / quantize notes routine. I'd left-click a part to select it and the quickly right-click for the menu and the sequence opened. Doesn't seem to happen in the "F" Releases anymore, or maybe I just adapted to MU.LAB's click intervals?

[MuTools]

Hey, you don't have to select a part to access it's context-menu.

Why not just right-click the part?

[Bonteburg]

Jo - that's exactly what I'm doing now!

I did some testing/self observation and apparently I've moved over to the right-click-only method already, that's why things are working better now.