MU.LAB 3.1 test

[Simon Posford]

The new MU.LAB 3.1.16 test patch is available in http://www.mutools.com/mulab/chestnut

What's changed:

• Tuned: Finetuned code in order to have a more solid play cursor while scrolling/zooming an editor

Mutool remember the choosing colour feature for the play cursor while you are in it
Anyway it's good to have more solid play cursor because Live or ext or cubase or reaper and many daw have all the same poor play cursor who flashing when they are on clips....Like i have said the cursor is one of the most visual thing used in a daw it's important to have a clear look!

Thanks for all the new features i have bought gp6 my next buy 'll be for mulab

[MuTools]

Mutool remember the choosing colour feature for the play cursor while you are in it

Maybe i understand wrong but: It's already implemented i.e. the play cursor is fully skinnable.

In the chestnut webfolder there is a PositionLine.zip file.
Put the two files in that zip file into the Mulab/App/Graphics/LooxSkinName/Common/Common/Formats subfolder and restart MU.LAB and there you are.

Of course you can color that .Png file as you like.

And of course this PositionLine graphic will be included in the MU.LAB 3.1 release package.

[Simon Posford]

Oups yes sorry i was focused on the cleaned code and forgotten that you just say about this in the earlier post.
Well now only the time strip bar and mulab 'll be 100% fully skinnable!
Sorry for this mistake however i understood batter now what to do with positionline.zip

[MuTools]

The new MU.LAB 3.1.17 test patch is available in http://www.mutools.com/mulab/chestnut

What's changed:

• Tuned: Right-click empty rack slot -> context menu now also offers "Insert Module"
• Tuned: Optimized single part click in composer (could be a bit slow on slower systems)
• Tuned: Further finetuned double-click detector
• Tuned: Renaming tracks allowed even if track has target module
• Tuned: Double-click track name edits track name
• Tuned: Right-click on track module icon pops up that module's context menu intead of the track context menu (right-click track name for track context menu)
• Fixed: Replacing a module that was used as a track target did not propery update the relevant track(s)
• Fixed: A couple of issues with auto-naming

If you already have installed MU.LAB 3.1.4 or later, then simply replace the current MU.LAB application file with the new application patch file.

This is MU.LAB 3.1 release candidate 6.

[MuTools]

Another quick beg for the ability to rename tracks with targets -- I've run into another situation where this is a pain - multi-timbral synths/samplers. I have a sampler with a bunch of different percussion patches on different channels, and of course every track targetting it displays the same title and I can't do anything about it. Another situation where having the target displayed is less clear than user-chosen names, and more maintenance work renaming parts in multiple tracks along the timeline if you want to quickly know what track is what....

You got it For your arguments are true.

Checkout the new MU.LAB 3.1.17 test patch.

[robenestobenz]

The new MU.LAB 3.1.17 test patch is available in http://www.mutools.com/mulab/chestnut

What's changed:

• Tuned: Right-click empty rack slot -> context menu now also offers "Insert Module"
• Tuned: Optimized single part click in composer (could be a bit slow on slower systems)
• Tuned: Further finetuned double-click detector
• Tuned: Renaming tracks allowed even if track has target module
• Tuned: Double-click track name edits track name
• Tuned: Right-click on track module icon pops up that module's context menu intead of the track context menu (right-click track name for track context menu)
• Fixed: Replacing a module that was used as a track target did not propery update the relevant track(s)
• Fixed: A couple of issues with auto-naming

Now, I don't often use emoticons... but:

[*]Tuned: Renaming tracks allowed even if track has target module
[*]Tuned: Double-click track name edits track name

Loving the 3.1 versions, thanks!

//edit: The double click locator / transport placement is feeling much more responsive with the last couple of versions as well.

[MuTools]

To all waiting for more sensational changes to MU.LAB 3:

I think it's very important to really finetune a release version. It doesn't make sense to develop an app at high speed while half of the features are 'unfinished'.

That's why i invest quite some time in finetuning this MU.LAB 3.1 release version

Hope it will be worth it and MU.LAB 3.1 will be a joy to make music with

[cytone]

Not sure what other people think but to do a double click now you have to do it faster than normal in windows. Spending a few minutes with it I'm finding it a bit hard to use

[janamdo]

Hope it will be worth it and MU.LAB 3.1 will be a joy to make music with

It is already a joy to use MULAB
You have to do what you have to do..
I as user give only ideas, you can do as you like to make MULAB a commercial succes

[liquidsound]

Better and Better!

[liquidsound]

Not sure what other people think but to do a double click now you have to do it faster than normal in windows. Spending a few minutes with it I'm finding it a bit hard to use

It's not so extreme but it's true.
Also, if you click Left and Right buttons in fast sequence you get the equivalent of Left Double Click. This may help but it's wired!

[MuTools]

Not sure what other people think but to do a double click now you have to do it faster than normal in windows. Spending a few minutes with it I'm finding it a bit hard to use

The double-click examination time in MU.LAB has not changed, it's the same as in MU.LAB 2.7 and MU.LAB 3.0 i.e. 300 ms, which indeed is less than the default windows double-click time frame of 500 ms. (can't immediately find the default double-click time frame in OSX but i assume it won't be that much different).

What has changed (besides some optimizations that were undoubtedly good) is that the mouse up of the first click is also taken into account, and that makes a difference. The advantage is that non-double-clicks (i.e. single clicks) are detected faster. But indeed at the cost of having to do more snappy double-clicks.

Although i think it's a also matter of getting used too, i can also understand that not everyone feels equally comfortable with this new double-click feel.

We could remove that first-mouse-up criterium so it will feel the same as before. (the other optimizations can stay in place and give a slightly more responsive double-click feel anyway). But then i think we must also remove the 'double-click in timebar = add locator' feature because otherwise the "single click = set play position" feels to sluggish.

Or we could set the play position on the first click and if there is a double-click, then also a locator is created.

So the choice we have is

A) Keep snappy double-clicks and double-click = create locator in timebar. (cfr 3.1.17)

B) Return to the more relaxed double-click feel and on double-click in time bar both the play position is set as well as a locator is created i.e. on the first click the play position is set and if it's a double-click then also a locator is created. (new option)

C) Return to the more relaxed double-click feel and remove double-click = create locator in timebar. (cfr 3.0)

So what do you guys think is the best choice for a wide user base?

I.e. for younger people and older people, more newbie users and more power users.

[cytone]

B looks a good option to me.

[robenestobenz]

Maybe I'm just a natural fast clicker, but I hadn't even noticed that MuLab has always had a narrower time band for double-click detection than Windows.

Think of others though, option B.

//edit: misread the original post -- yeah, I have no problem with a slightly longer delay on the play position click, so changed option to B.

[liquidsound]

Whatever is more appropriate for the future development of MU.LAB.
I can always get an Expresso and click accordingly