Difficulties with MuLab

[feijai]

I have been playing with the free version of MuLab and pondering whether to buy it. But I have some concerns, and I'm wondering if they will ultimatley be addressed.

1. Mac Interface. I understand that MuLab is designed to be a portable solution, and perhaps it would work really well on a tablet. But on OS X this is a very poor experience, I am saddened to say. A few examples: (A) MuLab ... has no Mac menus at all! (B) It is amazingly easy to accidentally resize the window so that the title bar is hidden under the Mac menubar and then you're screwed if you don't know the "Move to Top Left" secret. (C) MuLab doesn't support Mac standard drag and drop interaction, inter-application cut-and-paste, or text selection (for example, choose Rename Track, then type some text, then try to select some text in the middle of it). (D) Open/Save panels are highly nonstandard and inferior. (E) MuLab doesn't follow Mac traditions like buttons whose labels are verbs, opting for Windows stuff. (F) Right-clicking or two-finger tapping is inconsistent -- sometimes it brings up a context menu, sometimes it (!!!) deletes notes. (G) Trackpad-scrolling in the note area is mapped incorrectly to zoom, rather than, you know, scroll, and to make matters worse, both directions of trackpad scrolling are mapped to zoom in the *same direction*. (H) Resizing the window isn't live. And so on.

I realize some of this may be due to MuLab's (perhaps unfortunate) choice of interface toolkit. But while Windows and Linux users are more tolerant of nonstandard UIs, this stuff is really important to many OS X users. This toolkit behavior very much makes OS X feel like a second-rate afterthought platform for MuLab. I would prefer a DAW which acts like it wants to be part of my operating system.

[As an aside, "This will stop the Audio Engine, Okay?: YES / NO" is a poor interface, as neither Yes or No say what's going to happen, which is that Yes calls up the Audio Setup box, and No cancels that operation. Apple (and NeXT before it) had naming standards which are still the best in the industry: a button should be labeled with a verb specifying exactly what's going to happen when you press it. So a Mac application would have made this "Starting Audio Setup will Stop the Audio Engine. Proceed?: START AUDIO SETUP / CANCEL"]

2. NRPN. It doesn't appear that NRPN is supported at all, certainly not as output. This is a big deal: for example, the Oberheim Matrix 1000 (firmware 1.20) can only be controlled via NRPN. This is pretty incredible. If I I want MuLab to control it, I'll have to build a piece of custom mapping hardware.

3. Drum kits appear to be fixed to 12 drums. Bad for those of us who have 16 pads.

4. MuLab spends a lot of time bugging me with dialog boxes, for example when I resize a sequence, when it should either (1) give me an the option of saying "always do this, don't bug me any more", or (2) give me several different ways to [for example] resize a track, such as control-drag or option-drag or shift-drag, each changing the cursor to a unique icon, or displaying some pop-up tooltip text, so I know what's happening.

I like MuLAB: it's a hell of a lot more intuitive than Ardour. But its interface experience and lack of NRPN has been frustrating. I just don't know if I should look elsewhere.

[Basil Watson]

Read my next post.

[Basil Watson]

I hear ya.im wondering if there is a more stable older release out ther.

[Michael L]

I am an early Mac user, too. I have many great audio apps (e.g. free-standing synths and audio editors with workspaces) without all those features. Because MuLab is a modular daw/synth environment it cannot have a hierarchical menu because commands depend on where I am in the Matrix. But that flexibility adds real benefits. When I "Think Different" in MuLab, I can combine modules (eg. 2 MuDrums), functions or shortcut keys to make it happen.
(...and if Apple moves SoundDiver out of beta you can control your Obie!)

[paradiddle]

I would have liked 2 fingers horizontal scrolling without clicking on the trackpad (in compose/edit). I find it irritating. My opinion of course.
Maybe settings for mouse gestures that could be user defined?

[Michael L]

Don't forget:
https://mutools.com/info/docs/common/ed ... ation.html
Perhaps we could have a thread on the piano roll workflow as a whole (mouse + context menu + dialog box + trackpad gesture + shortcut keys + modules) in the next development cycle? There have been several recent posts on that topic.

[feijai]

I have many great audio apps (e.g. free-standing synths and audio editors with workspaces) without all those features.

I'm sorry, but quality commercial Mac products have menus and properly interact with the OS X GUI.

Because MuLab is a modular daw/synth environment it cannot have a hierarchical menu because commands depend on where I am in the Matrix.

It's fine to have pop-up menus for certain custom stuff. It's not fine to violate Mac GUI standards across the board. Consider Final Cut Pro, for example, a program that is far more complex than MuLab, with far more modular options. It works with a menu and other GUI standards just fine.

Good GUI design is hard. That doesn't mean a commercial product should just throw up its hands. I strongly think that if MuTools wants this product to be a serious contender, it needs to design something consistent with the expectations of users in the environment in which it is running.

As an aside, I was trying to add some Mac-style shortcuts and discovered two apparent bugs in the shortcut facility

(1) CLOSE incorrectly always tries to close the main window, even if another closable window (such as the Modular panel) is in front of it. A close function should always close the front window.

(2) HIDE does not work at all , though MINIMIZE appears to work.

[MuTools]

I'm sorry, but quality commercial Mac products have menus and properly interact with the OS X GUI.

If quality is important to you, please start by convincing Apple to create a stable OS. With stable i mean that they should not break compatibilities all the time. MacOS is known to break app + driver compatibilities with almost every new (main) version. As a result of that situation the only way i, as a single dev company, can support MacOS is to take enough abstratction of it. So to be honnest and straight with you: What you're asking ie. more specific MacOS support and deeper interation with native MacOS is explicitly not planned, at the contrary, i'll try to avoid it as much as possible until MacOS gets stable. Hope you understand my reasons. That said i'll continue to further finetune and improve MuLab's multi-platform UI. I hope you appreciate this straight answer and that it helps you to choose the right MacOS tool for you.

It is amazingly easy to accidentally resize the window so that the title bar is hidden under the Mac menubar and then you're screwed if you don't know the "Move to Top Left" secret.

Point taken. It's already bounded wrt moving windows, but in the next version i've made sure it's also bounded when resizing windows.

Right-clicking or two-finger tapping is inconsistent -- sometimes it brings up a context menu, sometimes it (!!!) deletes notes.

For many years quite some users have requested that right-click notes = delete notes. I've refused to do so cause i didn't want to make an exception to the right-click = context menu rule.
But then ok i admitted/conceded to that FR so i added the requested right-click = delete notes feature. And now several users are complaining about it Ok i'll add a user preference about this aspect.

CLOSE incorrectly always tries to close the main window, even if another closable window (such as the Modular panel) is in front of it. A close function should always close the front window.

I doublechecked that and it works as you want. This is what i did to doublecheck it:
* Start MuLab, New Project
* Open Basic Synth editor
* Press [Esc] = closes the Basic Synth editor as expected.

HIDE does not work at all , though MINIMIZE appears to work.

Pls see this doc page for more info on the Minimize and Hide functions: http://www.mutools.com/info/docs/common/gui-info.html

[feijai]

I'm sorry, but quality commercial Mac products have menus and properly interact with the OS X GUI.

If quality is important to you, please start by convincing Apple to create a stable OS.

I shouldn't reveal this, but I've developed for OS X since it was called NeXSTEP 0.9. That's 1989. I have applications whose core GUI logic is intact that long. I agree with you, Apple changes its audio driver code every other day. Heavens, I had widely-used apps I developed which didn't survive Apple jettisoning *SoundKit* after Rhapsody, that's how long I've dealt with that [that's so old you may need to look it up ]. However, the Cocoa GUI code has basically worked the same for 25 years. Here's how consistent it's been: when you see "NSTextField", the NS means "NextSTEP". I don't think "Apple changes things" is a good argument for GUI development.

On the other hand, I understand you're a small, basically one-man company and resources are tough for doing cross-platform stuff. But MuLab deviates so much from OS X standards that it really is a hindrance.

Hearing someone else go on about how lots of OS X apps do this (they don't) I just grabbed Ableton Live 9 Demo for testing. It's got an interface which is, like MuLab, portable and completely unique. Buttons and text fields and labels etc. are all non-OS X, and yet their actual interaction with the OS is 100% compliant. The differences are just window dressing. Everything I mentioned before is entirely OS X standard on Ableton: text selection, drag and drop, cut and paste, window manipulation, scrolling, menus, mouse behavior, and so on.

Mind you, Ableton is built by a large team. But this is also the case for Audacity, Reaper, and other smaller-team products. Only Caustic is entirely OS X-agnostic, but of course that's a port of an *Android* application inside little more than a VM. Please consider making MuLab more OS X friendly: I really think it would go a long way towards attracting new OS X customers.

I doublechecked that and it works as you want.

Not for me. Here's what I get. OS X 10.9.5, MuLAB 7.2.17 64-bit:

1. Set Command-W to Close
2. Call up any of the following: (1) the Modular window (2) a VST -- for example, OBXd (3) a Synth panel
3. Type Command-W
4. Get: "Are you sure you want to close MuProject..... and Quit?"

It appears to be targeting the underlying window.

Pls see this doc page for more info on the Minimize and Hide functions: http://www.mutools.com/info/docs/common/gui-info.html

I see. So there's no OS X equivalent hide function at all?

[Michael L]

Hearing someone else go on about how lots of OS X apps do this (they don't)

I have many great audio apps (e.g. free-standing synths and audio editors with workspaces) without all those features.

To go on, these apps from top-quality developers (eg iZotope, BlueCat, IRCAM, AAS, UVI, ReCompose) all have 'low % OSX GUI compliance' so... some still Think Different TM

[MuTools]

However, the Cocoa GUI code has basically worked the same for 25 years. Here's how consistent it's been: when you see "NSTextField", the NS means "NextSTEP". I don't think "Apple changes things" is a good argument for GUI development.

Last year i finally updated MuTools' MacOS code base from using old Carbon to Cocoa. A necessary step without doubt. I agree with you that Cocoa is structured nicely, it feels logical, and at the start of the conversion i even felt enthusiasm. However there were several functions that were working very differently depending on which OSX version it was running on and those exceptions have taken lots and lots of r&d time + frustrating trial and error to find some way that works good on all versions of OSX. Of course i did not make a log of those difficulties so i can't simply list them now anymore but one i remember immediately is the NSBitmapImageRep drawInRect function with all kinds of weird quirks wrt performance, colorspaces, memory management, ... There were other similar bottlenecks during the Cocoa conversion, but again it's already too long ago to quickly list the details here. At the same time also as a Mac user i experienced several MacOS version incompatibilities eg suddenly couldn't use the good Roland SH201 anymore, couldn't install Kontakt 7 anymore, couldn't use AutoTune anymore, ...
Another recent MacOS quirk is that "GateKeeper Path Randomization" thing. Tell me: Why does Apple not allow the user to make the choice himself wether he trusts an app or not??
I've given it good thought and i think that making as much abstraction as possible from MacOS specifics is the best choice. The less dependent the Mu code is on Apple quirks, the better. Again, i do like the main Cocoa logic, it's very nicely structured, so i think it's generally less a NS issue but rather an Apple issue.

On the other hand, I understand you're a small, basically one-man company and resources are tough for doing cross-platform stuff. But MuLab deviates so much from OS X standards that it really is a hindrance. Hearing someone else go on about how lots of OS X apps do this (they don't) I just grabbed Ableton Live 9 Demo for testing. It's got an interface which is, like MuLab, portable and completely unique. Buttons and text fields and labels etc. are all non-OS X, and yet their actual interaction with the OS is 100% compliant. The differences are just window dressing. Everything I mentioned before is entirely OS X standard on Ableton: text selection, drag and drop, cut and paste, window manipulation, scrolling, menus, mouse behavior, and so on.

What's wrong with MuLab's text selection?
What's wrong with MuLab's drag-drop?
What's wrong with MuLab's cut-paste?
What's wrong with MuLab's window manipulation?
What's wrong with MuLab's scrolling?
What's wrong with MuLab's menus? (besides they use a slightly different approach to sub-menus)
What's wrong with MuLab's mouse behavior?

Looking forward to your specific details.

I doublechecked that and it works as you want.

Not for me. Here's what I get. OS X 10.9.5, MuLAB 7.2.17 64-bit:

1. Set Command-W to Close
2. Call up any of the following: (1) the Modular window (2) a VST -- for example, OBXd (3) a Synth panel
3. Type Command-W
4. Get: "Are you sure you want to close MuProject..... and Quit?"

It appears to be targeting the underlying window.

The issue in your specific example is that "Close" can have several meanings: Close Project and Close Window. In this specific case it is interpreted as Close Project. Solution: Map the Ctrl+W shortcut to Specific->Custom Window->Close.

So there's no OS X equivalent hide function at all?

Not sure what you mean. Minimize = OSX Minimize.

[feijai]

What's wrong with MuLab's text selection?
What's wrong with MuLab's cut-paste?

For example. Select a rack and go to Rename. The window "Explicit Track Name" pops up. Type a word, say, "FooBar". Now let's select the text Foo, copy it, and paste the copy after Bar, so it now says "FooBarFoo". Wait, I can't even select the text (!!!), much less copy it.

I shouldn't be so hasty about cut-and-paste though: if I copy text from another application, I can paste it successfully at the insertion point in that window. But I can't undo the paste (Command-Z). So the pasteboard facility seems to work, just not text selection or undo.

I've been unable to copy and paste sound data between MuLab and other apps (or in fact, paste MuLab pasteboard data at another point in MuLab!) but perhaps that's my ignorance. Certainly a number of audio apps don't have standardized pasteboard data types for audio (I don't think Audacity nor Live have it).

What's wrong with MuLab's drag-drop?

The big item I've noticed is that you can't drag MuLab objects out of the window, to export them to a file for example, or to mail them. You also can't drag them to the trash can, a common metaphor in OS X for deleting an object. You can't also seem to drag sound files into tracks. I do note that you can drag files or directories into the file dialog. But you can't drag them out.

What's wrong with MuLab's window manipulation?

For example, if you try to drag the project window while the "Explicit Track Name" window is up, you can't -- it's frozen! OS X strongly discourages modal dialogs, but even when you have one, you're always permitted to move the underlying window.

Similarly, if you bring up a dialog, then put (say) a Chrome or Safari window on top of it, then click on the underlying project window, it doesn't come up -- but the dialog window does. However if you bring up the Modular window, then do the same thing, the Modular window AND the project window come up, rather than just the underlying project window. Indeed, if you click on the Chrome window, the Modular window disappears (!) so it's being treated like a 1990s-style MacOS 9 dialog box rather than a real window.

Resizing is strange. MuLab doesn't buffer enough to keep up with resizing so you get big white regions before they get filled.

Double-clicking on the title bar of a window doesn't minimize it.

You can't tell whether the project has been edited in the normal way (a small dot in the close box -- btw, on the NeXT this used to be an X).

What's wrong with MuLab's scrolling?
What's wrong with MuLab's mouse behavior?

MuLab doesn't obey the user scroll settings. I have things set up so if you click on the scroll bar the scroll handle goes immediately there. MuLab doesn't do this -- instead it treats it as an old-style scroll-by-the-pageful command.

Additionally, two-fingered trackpad scrolling doesn't work right. Put aside its use for zooming for now and just look at the Modular window. There if you two-fingered drag up and down it scrolls vertically. But if you do the same thing horizontally nothing happens. Strangely, it *does* work horizontally for the Meta-Parameter list directly above.

As an aside, there's a bit of broken logic in MuLab's scroller. Grab the scroll bar handle and drag it clear to the top. Then continue to move the mouse further up a ways beyond the boundaries of the scroll bar. Then start moving down. What *should* happen is that the scrollbar waits until you get back into the Y-dimension range of the scroll handle before it starts scrolling. But MuLab instead immediately starts moving the handle.

What's wrong with MuLab's menus?

They don't exist. There's no menubar.

Pop-up menus are just fine, and I applaud MuLab's good use of them. But not having a real menubar, much less a thoughtful, honest-to-good effort to flatten commands, is not appropriate. Particularly when there are dozens and dozens of global commands available to bind to shortcut keybindings. Why do they not appear in a menubar?

The issue in your specific example is that "Close" can have several meanings: Close Project and Close Window. In this specific case it is interpreted as Close Project. Solution: Map the Ctrl+W shortcut to Specific->Custom Window->Close.

This sounds like a Windows thing to me. Why not just have close mean close Window, and whatever the top window is is the window that gets closed, be it the Modular window or the project window?

So there's no OS X equivalent hide function at all?

Not sure what you mean. Minimize = OSX Minimize.

On the mac, Minimize means minimize a window. Hide means hide the entire application. Try it in any OS X application. It's always mapped to Command-H.

[MuTools]

Thx for your detailed reply feijai. I'll reply in detail as soon as i can, but i had a little accident yesterday afternoon (nothing too dramatic) and i'll have to be careful with the amount of screen hours the next days. So it might take some days (maybe only next week) before i'll further reply on this, sorry about that.

[feijai]

A bit more on the two-fingered trackpad scrolling bit. On the Mac, two-fingered trackpad scrolling (and its one-dimensional predecessor, the mouse scroll button) are reserved to scrolling. Having it do some other task is very counterintuitive to Mac users; but it's particularly counterintuitive when it's been shifted to some other task in an environment which requires scrolling! Such as the compose region.

I don't know who asked that two-fingered scrolling be improperly mapped to zoom, but let me suggest that it be remapped to scrolling, and not just for OS X continuity reasons. It's pretty common to have a large number of tracks. Many of the most common tasks require that your cursor be at the far left of the screen where the track headers are. But since two-fingered scrolling is unavailable, to scroll through the track headers you have to move the mouse clear to the other side of the screen to the scroll bar, scroll, the go all the way back. This happens a lot.

BTW, poking around Live I find that they do scrolling via two-fingered dragging in the main region, and they do zoom by dragging vertically in the "overview" region. I'd not do that, I'd do something like shift-two-finger-draging or whatnot. But it works.

[MuTools]

feijai, thx again for your detailed reply. I regard some of your points as feature requests, independent from whether it's about the MacOS version or not. Eg copy-paste audio between apps, drag-drop data out of MuLab (dragging into MuLab is supported as you know), ... There is a long wishlist of feature requests, more about it in this post.

I can't even select the text

You're correct that lasso-selecting some text is not yet possible while it's a standard, taken note on the wishlist.

What's wrong with MuLab's window manipulation?

For example, if you try to drag the project window while the "Explicit Track Name" window is up, you can't -- it's frozen! OS X strongly discourages modal dialogs, but even when you have one, you're always permitted to move the underlying window.
Similarly, if you bring up a dialog, then put (say) a Chrome or Safari window on top of it, then click on the underlying project window, it doesn't come up -- but the dialog window does. However if you bring up the Modular window, then do the same thing, the Modular window AND the project window come up, rather than just the underlying project window. Indeed, if you click on the Chrome window, the Modular window disappears (!) so it's being treated like a 1990s-style MacOS 9 dialog box rather than a real window.

It sounds like 100% MacOS compliance is very important to you. Well in that case i must say that MuLab isn't the right tool for you. MuTools software will always have a multi-platform flavor and abstract a bit from the specific platform in order to optimize R&D. That said, i will continue to give enough importance and priority to a smooth workflow and general multi-platform software compliance.

You can't tell whether the project has been edited in the normal way (a small dot in the close box -- btw, on the NeXT this used to be an X).

In any DAW that uses VSTs it is impossible to detect wether a project has changed or not.
There is a related Q&A about that on this doc page: http://www.mutools.com/info/docs/mulab/ ... swers.html

What's wrong with MuLab's menus?

They don't exist. There's no menubar.

Appart from what i wrote above about MuTools software following a multi-platform standard, i want to say that i think that the MacOS common menubar approach is a wrong concept, for several reasons:
1) If you have a large screen and an app window is more at the bottom-right or on another screen, then you have to travel your mouse a lot before you reach the menubar. Uncomfortable, imho.
2) The common menubar concept implicitly means that you first have to click-activate windows before you can use its specific menu. Also this is uncomfortable.

Particularly when there are dozens and dozens of global commands available to bind to shortcut keybindings. Why do they not appear in a menubar?

Some functions are only accessible via a shortcut otherwise the menus would bloat too much.
Some of these functions are also in a group of similar functions so that the user can choose one of them for the shortcut.
Hope i explain well.

Conclusion: Eventhough i do understand and respect your points of constructive criticism, and while i will continue to improve the general look & feel and user comfort, i conclude we have a different view on things, especially when it comes to supporting MacOS specific standards.