Note displacement bug

[Kooi]

I recently begun using MU.LAB, and I'm really starting to like it. Its features, especially on the modular side, are impressive. At the moment the only drawback is its somewhat awkward usability.

But onto the issue at hand: there seems to be a bug related to adding notes with the pen tool. Clicking in certain parts of the grid places notes into wrong cells - see image:

It seems the note placement hitboxes (shown here in red) are offset to the left by half a width of a cell. This makes placing notes with the mouse quite difficult.

I'll keep an eye out for other bugs.
Keep up the good work, muzycian!

[muzycian]

I recently begun using MU.LAB, and I'm really starting to like it. Its features, especially on the modular side, are impressive. At the moment the only drawback is its somewhat awkward usability.

What user aspects do you find awkward?

But onto the issue at hand: there seems to be a bug related to adding notes with the pen tool. Clicking in certain parts of the grid places notes into wrong cells - see image...

This is not a bug but 100% intended behaviour.

Thing is that the mouse cursor is always snapped to the nearest grid position.

I'll keep an eye out for other bugs

Thanks!

[Kooi]

Thanks for the quick reply!

What user aspects do you find awkward?

First, the right-click menus are quite tiresome: often you have to click open the nested "folders" to get to what you are looking for. With the file browser this is of course a good idea, but most other menus would benefit from a faster, traditional view.

Second, I fail to see MU.LAB's multi-window system's advantages over a single-window, fullscreen environment. Without virtual desktops it is difficult to manage all the different windows. While the multi-window setup could be handy with two or more screens, on a single display it just complicates things.

And some smaller things:

The tool system feels clumsy at the moment - I would prefer using a single cursor mode with key modifiers.
Managing VST presets is difficult.
The (default) interface looks bloated, i.e., takes up a lot of screen space.

This is not a bug but 100% intended behaviour.

Thing is that the mouse cursor is always snapped to the nearest grid position.

Oh, I should have guessed that - but I still find it strange. For me it feels more natural to aim at the center of a cell than at a border between two cells. In my experience, this is also the way most hosts implement it.

But if it in fact is a matter of personal preference, maybe this could be turned into a user setting?

edit: By the way, the skin SDK page (http://www.mutools.com/skin_sdk.html) seems to be out of order, at least on Firefox & IE.

[muzycian]

First, the right-click menus are quite tiresome: often you have to click open the nested "folders" to get to what you are looking for. With the file browser this is of course a good idea, but most other menus would benefit from a faster, traditional view

Why do you find a 'traditional' popup menu faster?

You always have to wait until a submenu opens up, and especially be careful not to go outside it because then it disappears; i'm sure you know what i mean. So why is it better?

Second, I fail to see MU.LAB's multi-window system's advantages over a single-window, fullscreen environment. Without virtual desktops it is difficult to manage all the different windows. While the multi-window setup could be handy with two or more screens, on a single display it just complicates things.

Agreed.

Taken notes on the whishlist.

And some smaller things:

The tool system feels clumsy at the moment - I would prefer using a single cursor mode with key modifiers.

The next version has improved tool behaviour!

Check it out soon. (ETA of the release: end of june)

Managing VST presets is difficult.

With difficult you mean: difficult to find?

-> Right-click on the VST plugin name (in MU.LAB)
-> Choose "Choose VST Preset"

There you go, and chosing a preset from there on is pretty easy because the preset selector stays alive until you doubleclick a preset or press enter, return or escape.

Fyi: It's on the whishlist to attach this vst preset chooser to the vst editor. But there is a technical issue to be resolved.

The (default) interface looks bloated, i.e., takes up a lot of screen space.

On what screen resolution do you work?

Thing is that the mouse cursor is always snapped to the nearest grid position.

Oh, I should have guessed that - but I still find it strange. For me it feels more natural to aim at the center of a cell than at a border between two cells. In my experience, this is also the way most hosts implement it.

What do other users think about this?

Would it be better to do a 'per-cell' strategy here?

But if it in fact is a matter of personal preference, maybe this could be turned into a user setting?

Lets be careful with 'Preferences' because in the end there could be too many options. It's a challenge to make the software pleasant out of the box! Ok, offering preferences when really necessary.

edit: By the way, the skin SDK page (http://www.mutools.com/skin_sdk.html) seems to be out of order, at least on Firefox & IE.

It's on http://www.mutools.com/mulab/docs/skin_sdk.html

Where did you find that broken link?

Thanks.

[Kooi]

I think I found an actual bug this time: just shift-clicking on empty space (in either the composer or the key editor) causes a ½-second freeze, which thankfully does not affect audio. This only happens when the pen tool is selected, and you do not move the mouse after shift-clicking.

Also, trying to close MU.LAB while in piano roll mode just reverts to the composer mode, instead of exiting.

Why do you find a 'traditional' popup menu faster?

You always have to wait until a submenu opens up, and especially be careful not to go outside it because then it disappears; i'm sure you know what i mean. So why is it better?

It depends on the implementation - traditional menus can be very usable. But now that I think about it, the problem with the menus might be elsewhere.

Consider, for example, that the composer right-click menu has 3 submenus. When you open them all, the items still fit in the menu (which doesn't resize according to its contents)! Wouldn't it be more efficient to have all the items unfolded in the first place?

The next version has improved tool behaviour!

Check it out soon. (ETA of the release: end of june)

Sounds great!

Fyi: It's on the whishlist to attach this vst preset chooser to the vst editor. But there is a technical issue to be resolved.

This was just what I was getting at. Good to know it is being worked on.

On what screen resolution do you work?

I'm currently using 1280x1024, which isn't that small, but especially the racks seem to waste more space than they should (even when they are minimized). But if I understand correctly, this can be improved upon with skins, right?

Lets be careful with 'Preferences' because in the end there could be too many options. It's a challenge to make the software pleasant out of the box! Ok, offering preferences when really necessary.

That's an interesting thing to say, because in my opinion there almost never are too many options! As long as they are well organized - so that users aren't overwhelmed with things they don't want to change. The note placement preference, for example, might be found in Options -> Interface -> Advanced.

It's a good idea to remember that people have different tastes.

Where did you find that broken link?

At the end of tips & tricks (http://www.mutools.com/mulab/docs/tt-qa.html).

[muzycian]

I think I found an actual bug this time: just shift-clicking on empty space (in either the composer or the key editor) causes a ½-second freeze, which thankfully does not affect audio. This only happens when the pen tool is selected, and you do not move the mouse after shift-clicking.

Not a bug, it's normal.

When you hold shift when having the pencil, then the pencil can lasso-select notes. But it also checks for a doubleclick because then it starts a fresh selection i.e. it first unselects everything.

So the 'waiting' you observe has to do with the check-for-doubleclick.

Also, trying to close MU.LAB while in piano roll mode just reverts to the composer mode, instead of exiting.

Intended behaviour.

It's meant as an intuitive way to close the sequence editor.

Why do you find a 'traditional' popup menu better?

It depends on the implementation - traditional menus can be very usable. But now that I think about it, the problem with the menus might be elsewhere.

Consider, for example, that the composer right-click menu has 3 submenus. When you open them all, the items still fit in the menu (which doesn't resize according to its contents)! Wouldn't it be more efficient to have all the items unfolded in the first place?

Maybe. Someone else also suggested this.

My concern is to make the program very light and easy, neatly hiding complexity as much as possible, while complexity should be easily available when necessary.

Opening context menus with A LOT of choices is not friendly on the eye, right?

So that's why it defaults to folded submenus.

Now this could be a Preference candidate...

On what screen resolution do you work?

I'm currently using 1280x1024, which isn't that small, but especially the racks seem to waste more space than they should (even when they are minimized). But if I understand correctly, this can be improved upon with skins, right?

Yep

Lets be careful with 'Preferences' because in the end there could be too many options. It's a challenge to make the software pleasant out of the box! Ok, offering preferences when really necessary.

That's an interesting thing to say, because in my opinion there almost never are too many options! As long as they are well organized - so that users aren't overwhelmed with things they don't want to change. The note placement preference, for example, might be found in Options -> Interface -> Advanced.

It's a good idea to remember that people have different tastes.

True. Point taken.

Where did you find that broken link?

At the end of tips & tricks (http://www.mutools.com/mulab/docs/tt-qa.html).

Ok, will be updated.

Cheers!

[Kooi]

Thanks for taking the time to answer, and of course, for creating MU.LAB! I hope I'm not coming across as a nuisance; my intention is just to try to give feedback.

So the 'waiting' you observe has to do with the check-for-doubleclick.

The technical aspect aside, as a user it feels like a glitch (albeit a minor one). I'm sure the wait-for-doubleclick feature doesn't have to freeze the interface.

Intended behaviour.

It's meant as an intuitive way to close the sequence editor.

This implies that the sequence editor is a nested view, while it in fact is presented as an alternative to the composer view. I imagine most users expect that clicking on the close window button (X) actually closes the window - instead of switching its mode.

My concern is to make the program very light and easy, neatly hiding complexity as much as possible, while complexity should be easily available when necessary.

Opening context menus with A LOT of choices is not friendly on the eye, right?

So that's why it defaults to folded submenus.

Now this could be a Preference candidate...

I agree with all of this, but I would like to point out that the most needed features should be the easiest to find and use, not hidden deep inside submenus. For example, adding racks in the modular view could be easier (adding them in the rack view isn't an option, since this way they are automatically connected straight to audio out, rather than my master rack).
Fewer clicks = faster workflow = happier users!

By the way, it would be useful to have a hotkey for quickly toggling quantization (for those fine timing edits).

edit: I guess the thing that bugs me about the folding type menus is that they are disorienting: when you open a submenu, the other items shift in place. It feels difficult to navigate, since items are not always in their familiar places, if you know what I mean.

[muzycian]

I hope I'm not coming across as a nuisance

Absolutely not.

my intention is just to try to give feedback.

Happily received

So the 'waiting' you observe has to do with the check-for-doubleclick.

The technical aspect aside, as a user it feels like a glitch (albeit a minor one). I'm sure the wait-for-doubleclick feature doesn't have to freeze the interface.

Apart from the technical side, it doesn't stand in the way there.

The pencil only checks / waits for the doubleclick if you hold shift and you don't move the mouse. No other action is delayed by that. Right?

Intended behaviour.

It's meant as an intuitive way to close the sequence editor.

This implies that the sequence editor is a nested view, while it in fact is presented as an alternative to the composer view. I imagine most users expect that clicking on the close window button (X) actually closes the window - instead of switching its mode.

I think that the most intuitive behaviour when clicking the X of the sequence editor is to close the sequence editor, not to quit the application. The latter could even be annoying because 'unexpected'.

What do others think?

My concern is to make the program very light and easy, neatly hiding complexity as much as possible, while complexity should be easily available when necessary.

Opening context menus with A LOT of choices is not friendly on the eye, right?

So that's why it defaults to folded submenus.

Now this could be a Preference candidate...

I agree with all of this, but I would like to point out that the most needed features should be the easiest to find and use, not hidden deep inside submenus. For example, adding racks in the modular view could be easier (adding them in the rack view isn't an option, since this way they are automatically connected straight to audio out, rather than my master rack).
Fewer clicks = faster workflow = happier users!

The next version has a preference called 'UseUnfoldedContextMenus'

By the way, it would be useful to have a hotkey for quickly toggling quantization (for those fine timing edits).

A proper hot-key system is on the whishlist.

[Kooi]

The pencil only checks / waits for the doubleclick if you hold shift and you don't move the mouse. No other action is delayed by that. Right?

In case keyboard shortcuts are not affected (I haven't tried), then this just a cosmetic bug. If it's is troublesome to fix, it's not worth the trouble.

The next version has a preference called 'UseUnfoldedContextMenus'

Hooray for preferences!

[muzycian]

In case keyboard shortcuts are not affected (I haven't tried), then this just a cosmetic bug. If it's is troublesome to fix, it's not worth the trouble.

Ok, the next version got a little cosmetic change so that you don't see the check-for-doubleclick

[MachFront]

My very humble input here:

I'll have to agree with Kooi on the note-placement, Jo. It does make sence that the pencil tool should activate the cell it's pointing too/inside of, even if it is a little bit more to the right or left. In the cell = that's the cell I want to use, know what I mean?

In regards to closing the sequence editor, here I'll have to take Jo's side. I think far more people would be surprised and displeased if they clicked on the X to close the editor and found that the app itself had closed. (Honestly, I don't know why someone would do it or risk it, myself, but whatever)

(As a tiny aside, I kind of wish MU.LAB had it's own windows gui instead of the Windows...err windows. Know what I mean?) Anyway.

As far as options and preferences are concerned, I think there can end up being far too many. That is indeed something that needs to be kept a tight leash on (with a strong helping of logic, mind). Besides, isn't the whole point of MU.LAB to not overwhelm with features that many don't even need?
I put it to you that if someone needed many, many more features than MU.LAB offered, then MU.LAB just simply wouldn't be what they were/are looking for. No harm, no foul. Just a different thing. MU.LAB, I think, is already a preference in and of itself, no?

[muzycian]

My very humble input here:

I'll have to agree with Kooi on the note-placement, Jo. It does make sence that the pencil tool should activate the cell it's pointing too/inside of, even if it is a little bit more to the right or left. In the cell = that's the cell I want to use, know what I mean?

Yes. I also have the impression almost all other hosts do it this way.

No decission yet, but definitely strong arguments to change it...

As far as options and preferences are concerned, I think there can end up being far too many. That is indeed something that needs to be kept a tight leash on (with a strong helping of logic, mind). Besides, isn't the whole point of MU.LAB to not overwhelm with features that many don't even need?

I agree.

As less as possible, as many as necessary.

Note that a nice 'solution' to this aspect lays in the fact that some preferences only exist in Mulab/Settings/Mulab.txt.

There they don't hurt anyone, but they're available to be changed for advanced users.

This system will be used more in the future.

And the docs must have a section that describes any possible preference setting in that file.

Of course, really important preferences that affect almost every user will be editable via MU.LAB's main Edit menu -> Preferences.

[pquenin]

- note placement : I agree with Kooi. It's funny, I've never be aware of this before...
- menu : I like the way it is now, but it's cool to have a preference...
- X close the sequence view and not the application : the first time I saw this, I was surprised, but well, it's better the way it is.

[muzycian]

Note placement: In the next version, the note editor pencil draws per-cell

Menus: In the next version, there is a documented preference

[MachFront]

I can't wait.