xparq / mulab Goto Github PK

Allow glissandos, like many other DAWs (e.g. FL). Esp. for the "piano roll" keys in the Seq. Editor.
Both for recording, and for just quickly glancing through a range of keys (e.g. for samplers, drums).

[This was issue no. 13 in my old list sent to Jo.]

For a start, it could just be a simple highliter.
Add a way to select a scale type, load the associated definition (from a list of predefined factory presets + custom items in user lib), and use it to grey out "forbidden" roll stripes and notes in the Editor. (Of course, instead of literally "greying", it could be any other markup, e.g. say a faint pinkish color to distinguish accidentals from black/white key cueing. Or rectangle outlines instead of solid blocks; etc.)

Note: notes could still be freely added as before, with no restriction. (Actual restrictions could be added by some related feature later, as needed, both for editing and even recording.)

This could be handy for several reasons. One is to match the time-scale of multiple floating
editor windows of parts that have different lengths (e.g. an automation parameter track
along a piano roll, to align the exact the timing of events across the sequences).
Note: currently this doesn't seem to be possible because of the zoom restriction (see attachment).

Note: zooming in, OTOH, already seems to be unrestricted.

Implementation:

The most straightforward control of the zoom limit override could be Ctrl+Wheel and its pair: holding Ctrl while clicking the +/- buttons ("giving /control/ over" the zoom limit) temporarily, for the current action. (Doing nothing special for the "+" case.)
Although Ctrl+Wheel is used for scrolling, there's a very nice, fortunate opportunity to naturally and intuitively extend the functionality, without messing up the workflow:

1. Scrolling is only enabled if the content can't fit the view, i.e. when already zoomed out maximally.
2. At the limit of the max. zoom-out level (when the content is maximally shrunk), there's no scrolling (because the entire content fits the view).
3. In this case, if the user intentionally ("forcibly") repeats the currently defunct Ctrl+Wheel action, it could temporarily do an unrestricted zoom command (both ways: also /in/, for consistency).
4. If the user has zoomed /out/ ("-") even more (overcoming the limit), the view obeys and updates, with the obvious & expected deterioration of some visiuals. (Issues wrt. the rendering should be considered.)
5. If the user has zoomed /in/ ("+") so that the content can no longer fit the view, nothing to do: the next Ctrl+Wheel would just do scrolling, as usual.
6. Same thing, of course, with Alt, for vertical zoom/scroll.

(Not being familiar with it, I'm not sure of any Mac key assigment implications, though, but I'd guess there isn't any.)

[Note: this issue was item 49 in my private list.]

I don't know if MuLab does or can maintain a "clean/dirty" edit state, but if it's already available, or possible to do, it could mean one less nuisance.

If there's nothing to save, the quit confirmation should just be: [Quit | Cancel].
(And if there is some, then: [Quit+Save | Quit | Cancel] --> see #39 why this ordering would be preferable.)

Most (all?) of those values can be adjusted by dragging up/down, but sometimes it could be faster and/or more precise to just enter a value directly. Which is also possible, but now it requires a double-click to open an extra window displaying just the same value, but in an editable form, and then another click on the value field to actually get the cursor. Only then can the value be edited, after which another click is required for closing the edit window.

This should be simplified to just a single click into the property widget and editing the value there, in-place, saving it by clicking elsewhere.
(Note: cancelling the change should be available via Undo, consistently.)

Changes made to a part via the Part Property Panel can't be undone, except for Tempo.

The most prominent example is the track "headers", which have at least four separate areas with distinct functionality, both in terms of click, double-click, right-click, and drag-and-drop (but not the same way: e.g. some have different dbl-click actions, but share same right-click menus), all that with insufficient (or, in case of drag/drop: no) visual indication of when and which area/function is being engaged. E.g. even the tooltips are the same for each area, further blurring the most important perceptional feedback (hover) instead of emphasizing important differences. OTOH, functions like "Rename" is available via at least 3 different and visually distinct ways there, further increasing the risk of confusion.

(Note: although the icon, the label and the empty space do look different and distinct, but they look static, so their appearance neither does imply the availability of input functionality, let alone all that many different ones, nor does it provide clues about the differences between them.)

Triggering different functions on actions like click, right-click, double-click, hover, drag/drop etc. depending solely on different pointer positions over static graphics (like a label, or a small, static icon, in some homogeneous empty space), also within a usually dense area, is highly unexpected to people used to common UI practices. Surprising, unusual behavior like that reduces confidence in controlling the UI, and thus takes considerable extra (and unnecessary, i.e. avoidable) effort to learn all those subtleties. It's also likely to cause some frustrating hit-and-miss results for beginners in the trial-and-error phase (i.e. during the trial period, before deciding on a purchase).

Todo:

• As a minimum, different tooltips revealing the individual input objects/handles could be the quickest workaround.

• Giving feedback via some kind of hover-highlighting to indicate that the given areas, despite looking completely static, are actually sensitive (input) widgets.

• Optionally, some graphical clues could also be provided already on the static level (e.g. some "etching" around, and/or more coloring to the icon, also perhaps a subtle border around, or underlining of the track name etc.).

Similarly to finding the Panic button (#20), it took me quite a bit of googling & reading to realize that it's there, under the Record button, albeit indirectly.

Even though playback via the MIDI keyboard doesn't seem to be particularly delayed (and AFAICR, some tests showed ~20-30ms), there's some strangely prominent and consistent timing issue with recording from my MIDI keyboard. The recorded notes are so off that a subsequent Quantize would make things even worse, not better.

It may be just my system (at least I can't remember finding complaints from others about it).

Needs further testing. (I can't yet rule out issues even with my own tempo/hearing...)

In most cases the output of a rack should normally be some audible sound (an audio signal). But, for some operations, subtle effects on the signal flow can kill the sound with no immediately apparent reason, which may be quite frustrating, especially for beginners.

I think the sound could actually still survive in some cases. In other cases, when the situation can't be meaningfully resolved, there should be either a warning (see below), and/or there should be a way to "unplug" a module from the rack, without deleting it.

1. Allow signal to flow through in some cases that currently don't work
   
   E.g. if you add an instrument to a rack, it consumes input events, and outputs audio.
   But if you insert an additional instrument, too, the sound stops. It's rather confusing: one would expect the second instrument just becoming ignored instead (for not having an event input available), rather than breaking the signal flow (and sound) entirely.
   I don't know what exactly MuLab does with inputs/outputs, but I assume a signal is never blocked by a module that cannot consume it.
   Then, say, if a "greedy" signal processing logic is applied to utilize all available inputs/outputs as much as possible, this should result in the two audio outputs (of the two instruments) eventually being mixed together, so the normal audio out of the first instrument, and the "void" audio of the "inputless" second instrument should eventually appear as "no change", i.e. the first instr. working just as before, as if the second incompatible one, indeed, got ignored.
   Or, if some "non-greedy" algorithm is used to process inputs/outputs, then the incompatible module could simply be excluded altogether from the signal flow, keeping it "unplugged", and again: not disrupting the signal flow in any way.

2. Warning about breaking the signal flow
   
   Whenever there really is a good reason why there's no audio at the end of a rack (especially if it did have sound previously; BTW, note: perhaps even specifically supporting dedicated audio/event rack types, like with tracks, could be useful), and it's easily to detect why (e.g. a newly added module needs event input, but only audio is available), a warning about the specific cause could be helpful.

3. Allow "unplugging", in addition to on/off
   
   For a beginner, it can also add to the frustration/confusion that even turning off an offending module wouldn't fix problems with the signal flow. This is understandable, if one considers the physical "plugging/chaining devices with cables" metaphor, but then it could be just as useful and even expected to have the ability to unplug (and replug) all signals to and from a module without deleting it from the rack.
   Note: simply adding a third "unplugged" state to ON/OFF would probably be just enough. (E.g. green = ON, red = OFF (as typical for the standby LED of consumer devices anyway), and then grey would mean UNPLUGGED.)

Operations like "Export audio" seem to offer the app dir as the default location (for the file selector/browser), when fist launched, which is unlikely to be the preferred location in most cases.

A better initial default location for these items seems to be the project dir, if the project has been saved already, or some "user root/home" location, or some "work area" otherwise (if any such folders are defined in MuLab's storage layout model). The app dir should be used only as a last-resort fallback, if all else fails.

When editing a part (which is inside the main loop range) in the part editor, clicking Rewind or Forward sometimes refuses to move the play position marker as expected (and did in M7), but seems to get stuck at a position within the part's range.

The sticky position might be the "last clicked" cue point, but then clicking another one on the timeline seems to "free up" the position marker, so the next Rewind/Forward then seems to not get stuck, but move away to the next cue point (e.g. start/end of the part).

Can reproduce it (in 8.0.58) by clicking to a time position in the part editor, then immediately trying to Rewind/Forward: in about half of the cases (apparently randomly), the pointer gets stuck.

Note: doesn't seem to happen in the Composer.

Seems to be a regression since M7 (unless it's an intended effect of some not-immediately-apperent behavior/feature change somewhere).

1. Lasso-select currently don't seem to allow selecting ranges that don't entirely fit the current view.

2. Dragging items (to copy/move to another time position) is also limited to the current view.
In this case drag-and-drop may be considered to take preference.

2/a. For notes drag-dropping is not really practical anywhere else but the grid, and neither is it allowed currently (not even across floating editors).

2/b. Dragging parts is allowed to the Browser, e.g. for MuClips, which is fine, but the user could still be allowed to scroll, e.g. by holding the drag position just slightly over the edge of the view (e.g. practically on the scroll bar). There could also be a short time-delay, so a slow slide over the edge (to reach e.g. the browser) would not initiate scrolling. Or even some modifier key, or a toggle (e.g. Scroll Lock by default on Windows to enable it -- BTW, similarly to FL Studio, AFAIK).

Notes:

If the "hold-mouse-at-edge" solution would be chosen, it should then be the same for notes, too (despite not strictly necessary), for consistency.

Just checking whether the Browser is on or off would be a bad idea: the workflow would cost some extra conscious attention, and also the browser may not be the only thing to accept dropped parts etc.

Also, the Default Auto Scroll config. param. should not be used for controlling this behavior either (despite its seductive name :) ), since that's quite a different function (used only by playback).

When entering the Sequence Editor (from the Composer, either by double-clicking a part or clicking EDIT), the keyboard focus appears to not be fully initialized or set on the Note Editor:

E.g. Ctrl+A does select all notes, as expected, but then pressing Delete does nothing.
To actually delete the selected notes now with Delete, you first have to click into the Note Editor explicitly. (Which then has the adverse effect of deselecting the notes, so they have to be selected again. Pressing Delete will then work, deleting them, as it should have the first time, too.)

This warning comes in M8 beta 50 (but not in M7), when trying to merge basic, vanilla (MIDI) parts (e.g. one with a single note, and one which is completely empty).
Tried with a default Basic Synth track.

Can't left-drag parts (to extend to the left), after a certain zoom-out level, while the right-edge still remains sensitive.

Must zoom in temporarily to actually be able to grab the left part edge for resizing, and then zoom back out to the previous level. (Can be a nuisance with arrangements longer than a few minutes, with many short parts.)

(I suspect it's exactly because of the too easy double-click deleting, since that way practically all the double-clicks would trigger a delete, instead of editing... See: #27)

This may seem to be a minor, irrelevant change, and is actually also problematic regarding the already etched muscle memories of existing users, but considering just the situation itself for a minute, it would mean a subtle ergonomic improvement:

1. It's more cognitively streamlined, supporting the general "no-brainer routine" (and best practice) of "the first choice should always be the most common one and/or the safest bet" (all else being equal).

2. With this ordering, the most straightforward clicking actions will not be disturbed even if #38 gets implemented: in both the [Save+Quit | Quit | Cancel] case of "there are unsaved changes" and the [Quit | Cancel] case ("all clean, nothing to save"), the user can just always click the left button for the most common and also always safe flow, and always click the right one for Cancel. The one rare and "unsafe" click of [Quit without saving] that should require attention anyway, would be the second button, which would also be shown only when it makes sense.

To address (avoid) changing the clicking habit of old users, a preference param. could be added, with the current way being default.

It seems to be missing at least here, in Gain automation sub-tracks, but I vaguely remember not having seen it at some other places either.

Alt+click is the "standard" auditioning action in MuLab. It's a pity that you can't use it for parts (which would be especially handy, when arranging/composing several short fragments).

(This would be basically the same thing as previewing a MuClip in the browser.)

The preferred way of controlling on/off (here, in the Composer) could be holding Alt: just stop playing, when the Alt key is released.

[This was issue no. 14 in my old list sent to Jo.]

Easy-to-reach panic button (currently buried inside the Help menu, I only discovered that it exists at all after weeks, accidentally.

The Load/Save Preset button icons are not indicative enough of their function (or the difference between their functions), and they also look too similar (e.g. on my screen at 1680x1050, at 100% GUI Scale), appearing to be less straightforward then necessary:

Also, they are downright counter-intuituve, too, because the arrows point to the wrong direction. One would naturally assume that they hint the transfer direction of presets, e.g. loading from "somewhere outside" into the window, i.e. down toward the panel itself -- but, alas, that's actually Save, not Load:

So, a sufficiently tired beginner user could too easy overwrite existing presets accidentally with some junk state (the aborted result of some long, fruitless tinkering...), when one would in fact want to reload a previous, stable state, especially in case of a factory preset. (It sure did happen to me, for example.)

Many (note or part) functions need parameters to be entered via dialogs like this:

Often it's not obvious what to enter (a number? percentage? an int? float? and what range?), and what they'd actually mean/do. A few descriptive tooltips could spare some doc lookups there.

It took me a while to realize that e.g. items like "Rich Fifths" under "Chords" are not parameters themselves, but one-off update actions (functions) for the layer list.

E.g. a tooltip saying something like "(Re)set layers to..." could be helpful.

[This was issue no. 3 in my old list sent to Jo.]

All the other params are disabled for inactive layers.

Note: this got fixed in a beta version (around 8.0.52), just recording here for completeness, and also to have some more closed items. ;)

[Same issue ID (6) as in my private list sent to Jo.]

This may no longer be the case (or never was?), but if it is, it would be better to reconcile this behavior across all the value input controls. (Alt+drag for jumping to "important" values, Ctrl+drag for fine-tuning.)

Needs further testing. (This might have been just an early usage mistake of mine.)

[This was issue no. 15 in my old list sent to Jo.]

Preferably, also add a user preference to enable/disable this.

1. Although the property panel already nicely shows the the note/key name, a slight ergonomic improvement (enabled via a user preference) could be allowing to also see it right at the mouse pointer, when it hovers over a note, and also an empty grid cell: e.g. a faint "G#5" written inside the grid cell at the pointer (long note names truncated to cell size).
   (As a subtle touch, it could perhaps even show both sharps/flats, e.g. "Gb5" if entering the cell from above, and "G#5" if coming from below.)

2. Alternatively, just by hovering, some (subtle) highlighting of the key name on the left (to help navigating accurately) could also be nice, even if not doing anything at the mouse pointer. (Ideally, the user preference mentioned above should decide the method.)

3. Also, when holding Alt, the pointer already changes to a magnifying glass anyway. But it does nothing useful now. It would be a nice intuitive touch to actually show some information about the note/cell currently being "examined" with that magnifying glass.
   Initially just a tooltip (dismissed when releasing Alt, and refreshed when moving over another cell) with the note name/key name (actually both, because sometimes it would be nice to know the original key name of a renamed note). Later it could be extended to a multi-line info bubble showing various other properties, too. That may even become the preferred way of showing note (grid cell) properties, instead of the current fixed property panel fields.
   Also: when Alt+hovering over the selected notes of a chord (similarly to Alt+click monitoring), label each overlapping note (as described in 1. above).
   Note: this may not need a new preference parameter, only if users want a way to disable it.

[This was issue no. 12 in my old list sent to Jo.]

Seems like now the left one always wins.

Note: this is not about overlapping parts, but adjacent ones.
Still, #25 could fix this case, too: the Z-order (i.e. the last one clicked) could unambiguously control which part gets dragged.

See also: [note-z-resize] (53 in my old list).

Along the lines of #35, even more useful would be adding basic version control functionality:
just an autoincrement counter, with change log entries on Save (like "added reverb, fixed harmony etc." -- these entries can be just single-line data initially), plus some static, scrollable/copyable history view, to review what has been done.

Some visual feedback should properly indicate which note is being currently adjusted by changing its velocity bar. (Note: it's not the focused item.)
Also, unambiguously clicking and dragging a velocity bar should never change some other bar.
E.g., in the case illustrated by this image, click-dragging the middle vertical bar will surprisingly change the highest one, which is neither the one clicked, nor the one in focus, and not even the topmost one in the Z-order:

When I was an absolute beginner (which is most of the trial period I spent with MuLab 7), it was not immediately clear, when would double-click delete a part, instead of opening it for editing. Hence, it became quite stressful to double-click them (even though Undo could restore them after an accidental delete).

The culprit is that the sensitive area didn't appear to be indicative enough or logically linked to the delete function, or more accurately: there's not enough visual cue for selecting Delete instead of Edit (or vice versa).

(I could guess eventually, that it's going to be Delete near the part edge, when the pointer changes to resize, but it took more than necessary "accidents" to learn it. Of course, one can always go and read the docs, but such a basic feature should be intuitive enough to not warrant that.)

Note: it may also become more problematic as a song grows, and the zoom level decreases, and parts become smaller.

I have a minimal project saved to reproduce this on the latest 7.x

Wrapping around list ends should a) be either allowed or disallowed in all of these types of select widgets (preferably controlled by a user preference, see below), and b) should behave consistently in both directions.

1. E.g. when selecting waveforms, clicking the next arrow (>) at the last item does wrap around and selects the first item of the list, but then you can't step back (if you made a mistake or change your mind): the prev. arrow (<) will not wrap back to the last item, instead, it pops up an error box: "No previous file found".
   (Note: it's rather frustrating to walk step-by-step to the end of a long list of items, and then step one more (because you can't tell if the current item is already the last) to wrap over to the first item, and then not being able to go back one step to the previous item (i.e. the last one of the list) without opening and browsing the list.)

2. Selecting module/instrument presets fails to wrap around in both directions (i.e. also for the last item: "No next file found").

A user preference should control how wrap-around should work: a) always wrap, b) never wrap, c) wrap with warning (i.e. using the current popups (with different text) to notify the user, but actually doing the warp-around).

Also, to make the widget a bit more ergonomic, it could hint that the current item is the first/last, e.g. in the tooltips: the generic "Next ..." / "Previous ..." labels should change to "Fist ..." / "Last ..." in case the current item is the last/first.

The current project "Creator Info" is very limiting, it basically only provides one small, single-line text field.
(It may not be limited to one line internally, I don't know, but the UI certainly is.)

I keep manually adding README.txt files (mostly for todo lists) to my project dirs -- which are often only dirs in the first place just to allow adding that file... If the MuProject format + the GUI supported the same thing, that extra manual nuisance would not be necessary.

See also: #36

It is undoable in the sequence editor already.

Can't seem to reproduce it now, not even in v7.
(In v7, the whole property panel gets hidden, when no part is selected, and I do remember seeing empty property panels showing up, FWIW.)

Also: allow closing project windows only with Ctrl-F4?

I see there's an XML config file to set keyboard shortcuts. Nice!
And that Ctrl+Q is already set there. Also nice.

So, this now boils down to the question then: can MuLab support multiple hotkeys for the same function? (Some people might still want to keep their own platform's default exit hotkey.)

MuLab incorrectly assumes that the last dot-prefixed part of an entered name is always a filename extension, which is typically not the case for manual user input. (Tested with prj. and mux preset files.)

E.g. trying to save a project as example 1.2 will silently end up in a file named example 1 instead, because .2 will be replaced by .MuProject.

Also, example 1.2.3 will yield a base filename of example 1.2.

Apart from the fact that this makes it impossible to correctly save files with dots in the name, there's also a slight danger of losing content by mistaken overwrites (despite a confirmation):

• E.g. having a version called "example 1", then trying to save a new one as "example 1.2", an unexpected confirmation pops up for overwriting the "same" file. If not realizing what's going on, or not paying proper attention to every character in the name in the message, such a confirmation for the wrong filename might confuse unsuspecting users to accidentally believe that it actually was the intended name, but they just perhaps saved it before already, so they may go ahead with the overwrite in a hurried move, mistakenly overwriting the "base" version "example 1".

I suspect this behavior might originate in drag-drop support, where, in contrast with typing, dropped names, indeed, do tend to always have the extension.
If so, would it be possible to differentiate between the two input methods, and treat typed names as "sacred", never altering them (even when they do really seem to contain an extension -- because consistent, predictable behavior is still preferable), but chopping off the extension of dropped names only?

Known to be affected: v7, v8 (up to 8.0.65).

[This was Issue 42. in my private list.]

Some file/folder locations can't be edited directly in file-related dialogs (e.g. rendered audio filename, prj. folder etc.), only selected via the filesystem browser.

Sometimes (e.g. when only adding/changing a single character somewhere in the name would be all that's needed, or when copy-pasting paths from other applications etc.) it would be much simpler/quicker to allow typing directly in the file/folder name fields, instead of launching the browser (when the value is clicked), and doing the same thing there, but with several extra clicks.

(Incorrectly entered (nonexistent) paths would need to be handled later anyway, after clicking "OK" to start the actual save/export action.)

Somehow some context menus feel more messy than they actually are. :)
Esp. submenus, menu item groups. It may be because of the way some menu items are grouped and how they appear, but may also be due to some subtle context-dependent differences (e.g. the additional "Edit" commands here and there, or e.g. "Un/Mute" (in the Part menu section) in the Composer. but not in the Seq. Editor).

It needs some more investigation to figure out what exactly is causing that vague feeling of messiness.

In the sequence editor, dbl-clicking on an empty grid cell will create a note of some preferred "unit length" (as it should). This is probably one of the most straightforward, most common action there.

For the sake of consistency (and, thus, intuitiveness), that valuable "create-by-double-click" action in the Composer could perhaps behave a little more similar to its counterpart. I.e.: double-clicking an empty space there could also create a part of some preferred length, which is often not the same as the loop length (as done today): looped sections are almost always longer than just a single part.

Unlike dbl-click+drag, a plain dbl-click may not be able to guess the desired part length (and position) unambiguously, but a set of prioritized rules of heuristics, using "interesting" (cue) positions, may help.
(An initial idea for prioritizing could be "prefer creating smaller...", but the smallest possible part is always just a few beats, or even less (as per grid granularity), so then longer parts couldn't be created that way. Similarly, just "prefer longer..." is also wrong.)

A viable approach could be "expand until first cue", for both directions, separately. (And perhaps another rule to constrain size, e.g. via maintaining dynamic invariants, like affecting the expansion of one side by the cue available at the other side etc.)
A "cue" could e.g. be a marker (loop, or other), an adjacent part in the same track, the start of the song (i.e. the 0 time), or the end of the song (i.e. the right side of the last part) etc.

Note:

1. When dbl-clicking outside the loop, there may be no available clue to constrain the right position (the size) of the part. In that case, e.g. just the current grid granularity, or some avg. part length (of the same kind, i.e. MIDI/audio), or some other location-independent default size could be used.

2. Dbl-clicking inside the loop currently creates a part filling the entire loop period, which is probably rarely optimal. Therefore (perhaps via a user preference param.) that function could better be more explicit with Ctrl+DblClick.

It should also allow adding more layers without first editing the number of layers.
Then, the "Num Layers" field should actually become just a static indicator, for the current # of layers (not an input used for increasing the "array length").

[This was issue no. 5 in my old list sent to Jo.]

Unlike most MuClips, some remain silent in the browser, when the time position is set outside the loop section (in the Composer). (Also when looping is off, and playing is paused.)

It may (also) depend on other things, but this seemed to be how I could reproduce it (in 8.0.58; can't make it happen in M7, so it's probably a regression).

example.zip

The current (project-global) undoing (and redoing) actions outside the current editor context may result in the silent loss of valuable changes. Consider these scenarios (or skip them if you're aware of the problem):

• Edit a sequence, go to Composer, hit Play. Then try tweaking e.g. the tempo of a part. Not liking it, undo. Then try transposing. Not liking either, undo. Nothing happens. Try again. Nothing. Hmm. Try changing other things, too, like part swing, then undo again. Apparently nothing happens, so try again. Still nothing. Never mind, perhaps there's no undo for those items (which, indeed, happens to be the case, see issue #10 for more, but that's not even specifically important here).
  Now, those "nothing happens" steps have just silently ruined the melody in the last edited part.

• Or, move a part, audition, move again, and again, maybe change some other things, too. Not liking it, undo repeatedly until the parts supposedly get back to their original place. Since you don't count how many undo steps to make, you might easily hit one or two more, but still see the parts at their correct place, unaware of any possibly extra undo steps invisibly removing the last changes made elsewhere (in the sequence editor in the example).

Note: I appreciate that it may be convenient to undo changes made elsewhere, without the need for switching to the related editing context. But doing it "blindly" could perhaps only be practical for the most experienced users, for everyone else, it's just dangerous.

Possible solution(s):

• At least there should be a message somewhere about the undo/redo action. Toaster messages could do fine. (Just simple automatic tooltips at the mouse pointer or the PROJECT button, or a designated message popup area, doesn't matter.)

Optionally:

• Having a status bar would also be handy, for other features, too, but that should be possible to hide, so not 100% optimal. However, adding a status bar could allow extending the undo/redo message with a button for optionally switching to the editor/context relevant to the undone/redone action.

• With a status bar, it may also be possible to ask for confirmation, if the next undo action would happen outside the current editor (so potentially invisibly).

• Perhaps some actions should not belong to the project-global context (similarly to e.g. editing text in an input field, or actions in the browser etc.), but should be local to the scope of a particular object. But I'm not familiar enough with MuLab to suggest any such changes.

The Z-order of parts can't easily (or at all?) be changed, which can make it unnecessarily cumbersome to manipulate (e.g. resize) overlapping items.

Clicking a part should actually bring it to the front (top of the Z-order), which would make things like resize more straightforward, when an item is overlapped by another.

(Perhaps even a context-menu item ("Bring to front") could be added, but that's probably overkill.)

Note: in v7, going to the Editor and then back to the Composer did the trick, as a workaround.
(It brought the current part to the top.) In v8, I can't seem to be able to do it now.

See also: #26

Would it cost too much to update the UI while recording?
Perhaps another menu-item toggle (on by default): 'Update Display` could be the best way to handle it.