MU.LAB 2.0 PreRelease

[pljones]

When you have auto-hide on Windows, Windows reports there being no visible task bar, so that applications get the whole screen. (Indeed, the task bar will normally hide part of the application window.) However, they're assumed not to be "on top of" the task bar -- the task bar is meant to be on top of everything. That way, you can always get your pointer into the one or two visible pixels. MU.LAB seems to insist on being on top of the task bar, so it doesn't get mouse over events.

[MuTools]

Thanks for the explanation, i understand more already.

But can you confirm that, when you shrink the mulab main window a bit (couple of pixels), and you hover the task bar lines, then the task bar unhides and is on top of mulab. It is the case here, but i have an impression, as i read the messages here, it's not the case on other systems.

[MuTools]

I just checked some other hosts regarding this window <-> taskbar issue, and in ext, reaper and flstudio it's all the same as in mulab:

When the main window is maximized, the taskbar lines are not visible, you have to resize the main window a little bit to make that taskbar lines visible. Normally this only has to be done a single time as the window size is memorized.

I'm not saying this is perfect, but i think it's just that Windows doesn't give the necessary possibilities to do it better

[pljones]

In Reaper, I can have the window maximized and move the mouse to the bottom of the screen and the task bar appears. Reaper's window acts like any other MSWindows window (as that's what it is).

In MU.LAB, with the window maximized, I can't use the mouse to get the task bar. If I use the mouse to drag the bottom of the window up to reveal what's under it, I still don't get the task bar appearing when I mouse to the bottom of the screen. (However, next time I run the app, it has remembered the size and the task bar appears in response to the mouse.)

[MuTools]

Note that if you right-click the Windows start button -> "Properties" -> "Task Bar", then you have the choice whether the Taskbar should be on top of other windows. If you enable that, then the taskbar should come on top of the mulab window. Can you confirm?

It may be that we had a different Windows settings for that parameter, and so that could explain the different 'on top' behaviour.

Personally i don't understand why it would be disabled. What's the purpose of a Windows taskbar popping up when it's not visible. Or i'm missing the point, or i call it a Windows quirck.

Now there is still 1 Windows issue to workaround

IF the taskbar is set to auto-hide, then MU.LAB could take that into account when calculating the maximum window size so to not be on top of those 2 lines, in contrast to what Windows suggests.

I've done some research and it's technically possible, so i guess that's the way around to go.

[MuTools]

In Reaper, I can have the window maximized and move the mouse to the bottom of the screen and the task bar appears. Reaper's window acts like any other MSWindows window (as that's what it is)

It's not the case here.

If i maximize the reaper window, and move to the bottom of the screen, the taskbar does not appear, even when i have enabled 'on top of other windows'.

In fact, it's not only with reaper. Even while typing this post in a maximized Explorer window, when i go to the bottom, no task bar appears

A Windows quirck i think.

[goyya76]

and...feedback to the hardware controller?

How do you exactly mean?

hello! for "feedback" i mean a bi-directional flow between the hardware controller (i'm thinking to controller with encoders like the BCR2000) and the host: i move a knob on the controller->the knob on the screen moves, i move a knob on the screen->the leds on the hardware controller are updated...

That would be useful also to avoid "jumping" knobs and faders (i hope i'm clear enough!)

ciao,
Goyya

[MuTools]

Ok, understood.

[jens]

I like to use auto-hide on the XP taskbar, and Mu.Lab sits rather rudely over it in such a way that I can't see my taskbar when it auto-unhides. I can use the window key to bring up the taskbar, but that means an extra trip to the keyboard; and I could resize the Mu.Lab window, but that's lame, because the whole purpose of the auto-hide is to maximize screen space while retaining the ability to quickly use the taskbar.

I'm not sure if i understand.

When i enable "Auto-hide the taskbar", and then maximize the mulab window (which is also done automatically the first time you run mulab), then indeed the mulab window goes full screen and it even covers those 2 blue lines at the very bottom of the screen which are used to unhide the taskbar. That is because mulab asks Windows for the maximum possible rectangle for a window, taking the taskbar into account, and then that's what Windows tells to mulab. So i guess Windows is returning a bad suggestion..?

Anyway, if you resize the mulab window so it becomes 2 pixels less high so to uncover the small taskbar top, then doesn't that solve the problem?

Because if i hit the small taskbar top, then the taskbar unhides, and it's clearly visible on top of the main mulab window, right?

Hey i'm not saying i don't want to do anything about this, at the contrary, the above are just some questions in order to understand what you guys mean, and whether it works the same on your systems than on my local system.

I really think this is a non-issue - you just need to press the windows-key to make the taskbar reappear.

[admc]

Do you agree?

As pljones told, it's not so easy to solve totally the problem the overlaying tracks. In MU.LAB Unlimited, your recommendation would be a good solution.

However I feel it more important to reduce the "width of sensitivity" of the part-resizing tool. Now when moving the mouse over a track, it takes the half of a beat when the resizing tool appears and mouse cursor changes, and since then, moving the part there is unable.

It's just too wide!

But if you think that this wide-sensitive tool makes easier to resize the parts, it would be a good solution, too, if pressing a key, for example, Shift, the resizing tool was disabled and one can move the part, holding the Shift key.

[tomica]

taskbar/start menu problem with mulab 2 explained in video:



the sound is quirky but it had to be so because my upload speed is wack.

[pljones]

If I had a YouTube account, I'd vote for your vid

[MuTools]

It's just too wide!

But if you think that this wide-sensitive tool makes easier to resize the parts, it would be a good solution, too, if pressing a key, for example, Shift, the resizing tool was disabled and one can move the part, holding the Shift key.

I don't think it's too wide, the width gives comfort.

But in the next version, when the cursor hovers the start/end and becomes a pencil, then holding [Ctrl] will switch to the arrow

[jens]

taskbar/start menu problem with mulab 2 explained in video:



the sound is quirky but it had to be so because my upload speed is wack.

WOW - you even went to the length of creating/uploading a video...


like I said: you only need to press the Windows-key (the one between crtl and alt) and you'll get your taskbar back.

and b.t.w.: Reaper also has got a maximized mode, which behaves exactly in the same way as MuLab.


I don't see the problem, really.

[MuTools]

taskbar/start menu problem with mulab 2 explained in video:



the sound is quirky but it had to be so because my upload speed is wack.

Thanks for the cool example!

Just for my honor i want to say it's more of a Windows issue than a MU.LAB issue because MU.LAB uses standard Windows windows (of a certain type), and uses Windows' recommendation regarding maximized windows.

But as messaged above, based on your feedback i've added a workaround so that, when using an auto-hide taskbar, a maximized window will be a bit (2 pixels) smaller at the side of the taskbar (default: at the bottom).

Thanks for your feedback on this, it's an important tuning i think because it's all about feeling comfortable.

Besides this, while watching your video, i wondered: is it good that mu.lab asks for [Open x] [Open...] [New] on startup?

Or wouldn't it better to just start with a new session and add a "Open recent" in the file menu, as most applications do?