Tabs behaviour change - Opening two scores on the same window

Came up many times in the forum

OTOH the current behaviour has been asked for numerous times too

Making is a Suggestion, AKA Feature request, as the current behavoir is By Design

See e.g. #336366: Each file opened with Musescore 4 editor opens into a new window (like alt + tab window, not tab), #338634: Ouverture de fichiers multiples, #338596: Clicking "New Score" or just opening a score in generael opens a new window, #338524: Creating a new score opens a new window, #338022: Opening multiple scores

See also https://github.com/musescore/MuseScore/issues/12647

this is waaay far a compromise!

moreover when running in full screen it is not possible to switch without closing or minimizing the active window, since it never releases the taskbar!??
it's definitely very surprising
and the whole thing is really too penalizing...

Are you saying Alt+Tab isn't working normally for you? Id eos for me on both WIndows and Linux.

sorry, I'm afraid I can't verify that point, I just downgrade to 3.2.
But I meant that lowering the mouse pointer to the very bottom of the screen does not bring up the taskbar, thus forcing to minimize the window

Why 3.2 rather than the much better and newer 3.6.2?

no idea !! but 3.6.2 is not (yet?) available for download

but many thanks to you, I found it!

https://musescore.org/en/download#older-versions
For Linux newer Appimage versions are on GitHub

No need to uninstall MuseScore 4 just to try out older versions - they can peacefully coexist. As mentioned, Alt+Tab works as usual, so the loss of the taskbar in full screen mode should not cause any special problems.

Yes but no ! it is precisely this page that stops at 3.2.
I found 3.6 here: https://musescore.org/fr/node/317219
(for Windows in my case)

it's out of habit to work with the mouse... I don't practice alt-tab.

another really annoying thing with this version 4 ... I just noticed that now version 3.6.2 can no longer open scores that V4 had modified! So no backward compatibility... ohoh not good at all that!!
(however musescore is still a marvelous creation. It absolutely has to be said)

Export to MusicXML in Mu4, import in Mu3

clever, thanks

I very deeply agree with the many user complaints about this new "by design" UI/UX frankly atrocity. It is so bad, that it really does discourage the use of the new 4 vs. 3 at all (and, what sucks in my experience at least, and I cannot nor have the time to explain why this is, but 3 always crashed for me – it is a guarantee, seemingly randomly (typically when doing something a bit more complex / computationally demanding, like, select all then perform some change of property of sth, etc.), the app will crash out of the blue and hopefully any work I've done in the last two minutes since auto-save wasn't critical or difficult to have to redo).

Please allow us to open multiple musescore files in ONE application window (specifically, I am on a macOS desktop). On macOS, a new application icon is created in the dock for every single new window¹. If this is by design, it cannot be considered "good" design. This cannot be by design, but by oversight.

¹ FURTHERMORE, even after closing the window (and this is the real crux of the issue where this cannot be "by design" – it has to be an oversight), these additional Dock applications icons in macOS persist. One has to explicitly right-click and then choose "remove from Dock" even after having closed down the window (even after having entirely shut down all instances of MuseScore4). So you see, macOS is confused, thinking that you are initiating new applications (not merely new windows) for each new window. What happens is in a single day of work one could end up with 20+ MuseScore4 application icons in their macOS Dock even after the program has been entirely shut down.

This is a bug.

USER CASE — EXAMPLE (See screenshots attached):
So for example, as a test, I opened many files at once, you can clearly see in the screenshot after the first MuseScore4 file is open (which uses the regular, single standard application Dock icon (as all other macOS applications behave - virtually). But then for all additional files beyond the first, "extra" new application icons are initiated and you can see those have piled up specifically in the section of the macOS Dock for "extra"/auxiliarily-instantiated apps. Curiously, if one does shut down the main first opened MuseScore4 window/"app" first, what happens (as shown in attached screenshot), is indeed all the other apps/windows (they should be windows, not apps!!), will attempt to close (notice them all jumping chaotically annoyingly excessively as one would expect - they are prompting "Are you sure you want to close before saving?" - of course).

In regards to my previous statement about "twenty" persisting "ghost" (if you will) MuseScore4 app icons, it seems there is some limit, actually, specifically of 3 (I would need to test further and see if this was related to the fact that I first closed the primary Dock MuseScore4 app icon/"window" - what would happen if I left that main instantiation of the app running and attempted to close all the extra windows? I wonder if more than 3 would persist as ghosts). Only 3 extra of these MuseScore4 applications icons will persist in the Dock once all have been shut down / closed ² (and mind you I had to one by one click on each dock icon to get to the window, say no I do not want to save shut down as I have hopefully wanted to do with one simple click). But aside from the ludicrous clutter this causes in the Dock while working with MuseScore4 running, the undeniable bug is that no extra/additional Dock app icons should be persisting once the program and all windows have been entirely shut down.

² And for those who may not be aware, on current (and for some time now) macOS, a small white circle beneath an app icon in the Dock indicates that that app is running. As can be seen in the attached screenshot here (displaying the 3 "ghost" MS4 app "extra" icons - persisting after complete shutdown): the lack of white circles beneath all of the four※ total, shows that I had entirely closed down the program.

※The main one, which should be always the only one ever showing; plus the three extra grouped at the right end of Dock.

→: Why are there now 3 permanent extra MS4 app icons in my Dock? This is the question/bug.

UPDATE
I did just discover a workaround, for macOS users (see attached screenshot for a setting that can be unchecked under the Dock System Preferences section), which eliminates the appearance of permanent extra MS4 Dock icons. But this is not ideal. This setting exists for a reason on macOS and is convenient in various other instances to have turned on; so one is forced to sacrifice the functionality of the entire OS, in part, for this workaround.

Also, I have not yet tried using MS4 again now. I am not sure what the behavior will be like now when I try opening multiple different projects. Again, in short/summary, it appears there was some oversight specifically in regards to how MS4 will operate on macOS, and more specifically, the macOS Dock.

(See detailed comment above where I rebut the defense of this being "by design" – it is a macOS-specific Major Graphical UI issue, detrimental to the use of the application.)

It is additionally an Ergonomical (UX) issue, which itself is hugely problematic. But the persisting ghost app icons in macOS Dock I provide example proof/evidence of demonstrates the severity overrides being merely ergonomic and is unfortunately instead outright Graphical software design oversight.

Hello,

I also would like to have the score tabs back.

In MuseScore 4 there are three tabs: Home, Score and Publish. 'Score' and 'Publish' are somehow the two aspects of a score, but 'Home' is not, so it feels like things are pushed here together, that do not belong together. Logically 'Publish' should also be somehow the child of the 'Score'.

I have also read elsewhere that each score needs a separate window because of the playback.
Can somebody tell me how the number of windows influences the playback?

thank you,
Tamas

MuseScore 3 had a very severe limitation because of the single window: all scores were forced to play with the same set of loaded soundfonts. This was just barely tolerable (but still a royal pain in many cases) when all you have to deal with are soundfonts. But it's completely unworkable now that there are Msue Sounds and also VST's. Forcing all scores to use the same sets of sounds would be completely unworkable, as would unloading and loading all sounds every time you switched tabs. Separate instances are the solution.

In general, it's a good solution - multiple windows are easier to work with than tabs within a single window on Windows and most Linux systems, including ChromeOS, because the OS was designed from the ground up to support this (heck, Micrisoft even named their OS around this). But macOS definitely makes multiple instances awkward because it doesn't manage the icons on the taskbar nicely like other systems do. So, it would definitely be good to find a solution to that shortcoming.

Hello Marc, thank you for your reply. I would be interested in why is the loading and unloading of the sounds tied to the number of tabs or windows? Tabs and windows seems to be a 'user interface' concern to me, and playback a 'backend' concern. Like for Chrome, you have a seamless transition between tabs and windows. Do the separate windows use separate processes, and separate processes are necessary to have multiple sounds loaded? Or why would you need to unload the sounds if you switch tabs?

It's not about the number of windows, it's about the number of "instances" (processes). By putting each score into a separate process, you can easily have different sets of sounds for different scores and the OS can manage the swapping very efficiently. Trying to do that within a single process - well, if you think you can pull it off, we welcome your PR implementing it!

Yes, I wanted to avoid looking into the source code. :)
If it is about the processes, then I think a single window containing the tabs could talk to multiple playback processes via some inter-process communication. Even seems a nice separation to me, could be challenging though on multiple operating systems. I see more and more programs using multiple processes, for example Chrome, so it looks like it can be done. But I don't know at which cost of complexity.
With the pro subscription and publishing scores I think I contribute to MuseScore sufficiently for me, so I don't plan to send a Pull Request, but thank you for answering my question.

Marc, this is very unfortunate. I understand that it is much easier to let an operating system deal with the process management (also at some point in Windows 11 new MS4 window crashes all of them), but this is not a good excuse to completely alter a good user experience. I've been constantly going back to 3.6.2...

... and yes, Alt-Tab works... as well as directly editing musicxml in either Oxygen or Visual Studio. ;)

As explained above, the reason for the change is efficiency and smoother workflow. There simply is no other known way to achieve the same level of smoothness when switching between scores that use different sound configurations - and forcing all scores to use the same sound configuration as MsueScore 3 would be very obviously unacceptable once you consider the new features of Muse Sounds and VST. So if you believe you have the solution, your PR to address this would be welcome, but so far, no one has found a way, so this is the best known solution to a difficult problem.

Not sure what you found preferable about having tabs that are essentially unreadable once you have more than a handful of scores open, compared to the elegant simplicity of Alt+Tab, but it's important to remember that preferences are personal, and that sometimes progress dictates that the needs of the many outweigh the needs of the few.

I've had a similar situation years ago when my team had to compromise some UX capabilities to maximize process effectiveness - it didn't end up well - we had to redesign a lot. Without looking at the source code (and I am not a developer anymore) I can't say exactly what can be done, however, you may look at the dynamic load/unload of sound configuration at the tab switch (so only one active config is loaded at a time).

As it comes to many vs. few, if you've done a VoC and know for sure that it is really many vs. few then it is fine.:)

It's certainly possible to unload and load sounds every time you switch scores - it's just incredibly inefficient. I don't think people would be happy if it took 10-30 seconds or more just to switch from one open score to another. That's why, again, the current situation is as good as anyone has been able to come up with, but alternative technologies are still being actively pursued as well.

I'm not familiar with the acronym VoC, but yes, usability tests are run often for all sorts of aspects of the user interface. I don't think, though, that anyone tried implementing the 30-seconds-to-switch-scores model just to perform a test of this versus separate instances. It's just a sort of common sense assumption that people wouldn't like that. Most modern operating systems are designed to make multiple instances work well and naturally, selecting between open instances either via Alt+Tab or by simply clicking in the list that appears when you click a taskbar icon. macOS seems to be the odd man out here, not supporting this model well at all, unfortunately. And that's why much of the effort being spent on this problem is being directed on how to work around that limitation specifically

I assume the load time depends on how much really needs to be loaded/unloaded, what "unloaded" really means and how many things are shared (I haven't seen the code), however, if you say 10-30 seconds it really is long. Also, depending on how many apps someone has opened the Alt-Tab can easily take the same 10 seconds.

VoC stands for "Voice of Customer" and there are several VoC methodologies that can be used for new product development. One important question would be to estimate "the customer population positively vs. negatively impacted" by a feature.
Also, for a test's sake, I've just tried to open 5 scores and the 5th score crashed them all. :(

Regardless of how many apps one has open, I've never seen Alt+Tab take ten seconds, that would seem to indicate an extreme RAM shortage that no amount of redesign of the application would solve.

One of the advantages of multiple instances is that it shouldn't be possible for one crash to affect other instances. Certain;y I've never seen this happen. But if you have a case where it does, best to ask for help on the Support forum and give more details. Then if someone else can reproduce the problem, you can open an issue on GitHub. This old-style issue tracker here has been retired and is no longer maintained.

I think my biggest gripe with this change is that I see a bunch of icons on my dock with no way of know what is what until I cycle through them. With 3.x I could see what the tab is called and instantly know what score I'm switching back to. It would be nice to allow users to toggle this feature.. I personally have no reason to have multiple playbacks going on at once, and never had crashes affect me to the point where I wish I had separate instances to mitigate it. While I understand this makes things easier for you guys under the hood, it makes for an extremely counter-intuitive and hateful UX lol I'm pretty much forced to downgrade back to 3.x.

I also think that while this is a free program, if you have so many users asking about this feature that its affecting the SEO of the program (Musescore 4 open tabs and Musescore 4 open windows come up before Musescore 4 open source - check it out), maybe you guys should pay attention to the complaints instead of telling people to front their own code. It comes off pretty snide and shows a lack of understanding of how people actually use MuseScore.

I don't think most people care about the technical details. This design is just horrible. Please add an option to open in a new tab, otherwise the new version would never be adopted widely.

It's all about why it's being used isn't it? If, like me, you're using it as notation software you don't care about playback quality or massive orchestras (I've got all that in my DAW, I don't need that here. a simple sketch of the sound is fine). And if like me you're working with lots of different pieces of music, mashing versions, it's been fabulous being able to just tab between the different versions, and pasting between them, etc. extracting certain bits I like. I shall be downgrading to 3 until this gets sorted. Shame as otherwise 4 looks good. And it still has the physical look of tabs. But a new instance of the software opening up for every new file? Nah.

I listed the inability of MS4 to open more than one score at a time to be a "bug". I can understand that using Alt+Tab is one workaround, BUT ... it only works with two songs. Alt+Tab goes from one open program song to another. If 3 scores are open, it does not jump to it, and you have to locate and click on its title somewhere in the taskbar at the bottom of Windows to display it, then copy/paste a piece of notation from it, then locate and click on the original open score using the taskbar at the bottom, then paste the notes into that open program, etc. It just seems a key step back from MS3.6, which may have used the same soundfonts for all scores but gave you the ability to quickly jump between all versions of a song easily.

Further, every time you launch a new copy of a program, you are taking up significant ROM, RAM, CPU and Memory.

So, I also support allowing one copy of the MS4 program to open more that one score by returning the feature found in MS3.6.

Alt+Tab lets you switch between as many open apps as you like, on every OS I've used - just press it multiple times as needed.

Also on most systems, locating the correct score is as simple as clicking the taskbar icon then selecting the score from the list that appears. This is actually simpler than selecting it from an open tab in that the tab names are often truncated and may scroll of the side of the window.

So its shouldn't be any hard to copy and paste between files in MU4 than in MU3, other than macOS which has a limitation in this area where each instance gets a separate icon.

It's a fallacy to assume that multiple instances requires significantly more resource than a single instance with many scores open at once. Operating systems are designed to handle this well.

Sorry to disagree, but when I press Alt+Tab multiple times, it does not jump from MS file 1 to MS file 2 to MS file 3, etc. Rather, it jumps from file 1 to file 2 back to file 1, back to file 2, etc. I in fact cannot reach file 3 using that method. I have to locate the file in the taskbar and then click on it. If I am somehow doing it wrong, please let me know. Nevertheless, we do have a difference of opinion. I enjoy MS3 and its ability to open multiple file tabs while in the same program, but if MS4 just cannot be made to do that, I guess we can all get used to using the taskbar. The key here is capability! If the programmers simply cannot get multiple tabs to work in MS4, then that is our reality. Alternatively, if they can, then eventually lots of MS users want to see it returned to the MS3 approach, based on the comments made here about this option.

As far as using system resources, three or four programs running at once always uses more system resources than running only 1 program. You are correct that most newer computers can handle it OK, but I checked my system resources with 3 copies of MS4 running, and they are definitely more in use than only one copy. That said, I stand corrected that my computer would strain to handle it. I have a multi-GB system and it doesn't really notice 3 copies running.

You’re on Windows, right? As I recall it’s a matter of continuing to hold Alt to show all open apps. It’s a very common operation since so many other apps work this way too, so Windows definitely supports it well. See for instance https://www.howtogeek.com/429223/master-windows-10s-alttab-switcher-wit…. Not a matter of opinion at all, just a Windows technique you apparently weren’t familiar with.

As for resouce usage, what you are seeing is the max needed, not what is actually needed at any given moment. Again, o this is such a common operation, operating systems are highly optimized to support it well.

Well ... I'll be! Never knew you could switch between files by holding down the Alt key and tapping Tab multiple times. Thanks as always. I learn something new every day.

As to opinions, I was talking about the topic of the post, not Windows ... the use of tabs inside the same single process in MS3 rather than multiple files running separately in MS4. I strongly prefer MS3's approach, but as I said, if that is too hard for the programmers to create, I will just get used to using Alt+Tab and different copies of files in MS4. Thanks for your comments. They are always most informative.

To be fair, you only just learned how to fully use Atl+Tab a few minutes ago, you might want to give it more a chance before jumping to conclusions.

There is a good reason why almost every other major program dealing in large documents uses a similar approach. It's not about what is hard for the programmers for to create - it's easy to do tabs, too. It's about what allows for greater capability (different sounds for different scores), which is generally more in keeping with modern design principles, and which which is actually handled more efficiently by modern operating systems. One can do tabs but then one sacrifices everything else.

I would add here that Chrome transitions seamlessly between application windows and tabs in a single window, and between how operating system processes are associated with tabs and windows.

Yes, but that's because Chrome doesn't have to load potentially gigabytes worth of audio every time you switch tabs :-). As explained previously, there's a reason multiple tabs isn't really viable anymore in a world of VST instruments, Muse Sounds, etc.

It was not wise to change this for a few people asking, when ALL the rest of us were quietly satisfied. How many other things do I now need to loudly pronounce (that I couldn't even imagine someone changing) that "I like the way this works!" If it ain't broke, don't fix it. Why didn't you just add "Open in new window"? Or add to what's now already done, "Open as new tab"? Bleh. I'm reading some people are regressing, just for the awkwardness of this one "As designed" feature.

agree with many others that this feature does not work nicely on Mac, which just doesn't really do "multiple instances of the same app." It's quite awkward. I'd also agree with others that the primary function of a notation app is notation, not audio, so I wish the audio experience didn't get prioritized here.

As explained, this wasn't changed because of a few people asking - it was changed as a necessarily in order to fully support VST and Muse Sounds in an efficient manner. No sacrifice was made to notation in order to do this, so that's a misrepresentation.

It is definitely recognized that macOS is pretty limited currently in its ability to support multiple instances, so alternatives are being investigated. no need to continue commenting here; the developers are well aware, and they don't see this defunct issue tracker anyhow.

I've noticed that a new version was dropped so I hoped it get fixed... I'm still on MS 3.
Marc, I'm sorry but a "smoother worlkflow" sounds like a bad joke.

How to customize a toolbox in MS4
- Assume I have opened 20 scores.
1. change whatever in toolbox or global settings
* changes apply to only to the current window, so I have to:
2. close 20 scores to save configuration, which involves:
* forcing to save all changes even if I don't want to
* loosing all undo/redo history
3. reopen 20 scores
4. THEN I can use customized toolbox in all scores

So by having multiple windows we
1. Severly damage undo/redo functionality
2. Force user to save scores whenever toolbox is customized
3. Damage performnce and waste time on meainingless reopening scores.

Also, Alt+Tab cycles through all apps. In multimonitor setup using workspaces/virtual desktops doesn't make sense. Also it doesn't give constant visual feed back. For example, a score which I want to see might be not open and I don't have an always-visible list of scores which are open. To check whether I've open a particular score open I have to scan a whole screen, whenever I use alt-tab or click on taskbar icon.

I've raised all of this in the past but it seems that MS team is concentrated on supporting a one-big-score workflow contrary to many-small-score scenario. Which would be okay if MS3 was still supported and it was clearly stated on the website: Download MS4 for orchestral music and great playback / Download MS3 for editing songs.

While multiple windows provide a great workflow for most things, it's true that it can make customization tricky, because there could be conflicting customizations. That could be solved by having customizations immediately communicated to other windows. I see you've already commented in https://github.com/musescore/MuseScore/issues/13837, but maybe this could be reopened as a feature request.

Also, as mentioned, it's known that macOS is pretty severely limited in its support for multiple instances; lacking the basic ability to collapse them into a single icon and show the names of the open scores in a single list etc So workarounds are being investigated for that.

"multiple windows provide a great workflow for most things" is nice way of describing a regression, but maybe I don't know something. So how to make a list of the open scores permanently visible on Windows? If I had that feature I'd consider switching to MS 3 (after customization is fixed ofc).

I want to:
1. Have an always visible, clickable list of open scores, which is visible inside MS window. (the most important one)
2. Have an ability to easily cycle between open apps, having MS as a single entry (currently I have to press alt-tab up to 20 times to get from MS to a web browser or a PDF viewer)
3. Have an ability to cycle between open scores only (not between different apps).

This can be achieved by moving the taskbar to the right and turning on labels, but this affects how everything is used.

WITHOUT resorting to virtual desktops, as someone suggested. Virtual desktops don't make sense in a multimonitor setup.

Windows itself provides the permanent list of open scores in the taskbar. That's kind of the point here - to allow the OS to do what it well by providing standardized access to the documents. It's actually far more visible than a list of tabs which unfortunately truncate score names plus limits you to only seeing as many as fit in the current window. But of course, a menu within MuseScore listing the open documents could be nice too, so feel free to open an issue on GitHub suggesting that as a new feature!

As for the fact that open documents will be intermixed with other programs - like the PDF viewers or DAW you might be using in conjunction with MuseScore - in many workflows that's a most excellent thing. In others it might happen not to be. I'm struggling to imagine a workflow where you'd need to often flip between 20 open scores without referring to any other program, or if such a case existed, why you wouldn't imply use the taskbar icon. I'm sure such a case exists somewhere in the world. but it's not likely to be as common as the more usual use cases. Which is why windows are thing. And why the most popular OS in the world is "Microsoft Windows" and not "Microsoft Tabs" :-) But anyhow, if MuseScore did provide the list of open scores, then presumably it could also implement a "next score" command to substitute for Alt+Tab in those cases.

Anyhow, again, there is literally noi point in responding to this defunct issue tracker. If you have questions about how to use MuseScore most effectively, please use the Supprot forum. If you believe you have new technical information to share on how to solve the couple of things that don't work as well currently (like the UI limitations of macOS or handling the issue of syncing customizations) then please follow up with your offer to help on the appropriate GitHub issue.

I think this is kind of a cop-out answer that this is now "by design". No, you broke a workflow that was there before.

The playback engine itself could be a separate process, acting as a server, which loads ALL the sounds that EVERY opened score project needs (and, of course, unloads sounds that are not used anymore when a score is closed). This way you don't need to invoke separate MuseScore instances, and you could revert to the nicer UX of MS3 with score tabs (way nicer IMHO). And since all required sounds would be loaded onto the playback server, switching tabs would be instantaneous. We have the RAM these days, use it!

This is also how software like Vienna Ensemble Pro works. It's basically a host for your sounds, you could open multiple DAW projects and they could all hook in to all the sounds you have in a VEPro instance.

I don't see what prevents MuseScore to work exactly the same way (apart from obviously coding the playback server up and all the ancillary things required).

This issue tracker here has been discontinued so better continue on GitHub , https://github.com/musescore/MuseScore/issues/12647

Indeed, I noticed this right after I pushed "Send". Posted on GitHub as well - thanks!

GitHub isn't the place for discussion, either. It's just to report an issue. For discussion, better to use the forum.

FWIW, I strongly disagree that tabs are better than windows. Quite the other way around. There is a reason the most popular OS in the world is called "Windows" and not "Tabs" :-) From my perspective, forcing everything into one window was a bug that is now fixed, and reverting to tabs would fix a workflow that is there now. But that's something to argue about in the forums...

You may respectfully disagree, but it is a workflow of certain people (including myself) who got used to that workflow. Removing that workflow is not an improvement nor a bug fix, it is a missing feature in the end.

I got a notification from this thread... I don't care a lot because I just stayed on 3.x, but was toolbox/settings synchronization fixed? Or does it still apply only to one window and all scores must be reopened after each change. I refer to the data loss issue I mentioned in my first comment. https://musescore.org/en/node/338910#comment-1201110

Re, "From my perspective, forcing everything into one window was a bug that is now fixed,"

I don't recall you ever filing a bug report about it.
It was not a bug: it was a design decision. The subsequent discussion about its omission in MS4 has centred around technical difficulties, not that it was a bug being fixed.

I miss the functionality where my previously open scores are opened again.

Windows was named 40 years ago, and many programs introduced tabs since then (web browsers, file browsers (Total Commander, file explorer in Windows 11), terminal programs (Windows Terminal), programming IDE-s), which apparently did not follow this reasoning.

Having tabs would not prevent you from opening all your scores in a separate windows, but removing the score tabs forces us to use separate windows. There was no "forcing everything into one window" in the first place.

On the other hand, there are tabs in MuseScore right now, just used in a way that is counter-intuitive for me: tabs should contain elements adjacent in a hierarchy (like several scores). Instead, there is now "Home" in a tab, then "Score", which is conceptually "below" Home, and "Publish", which is conceptually "below" a single score, since it's about publishing of that score.

So, for me, "I don't like tabs" is not a valid reason for preventing users from using scores in tabs.
"We don't want to deal with the extra complexity in our code" would be a valid reason for me.

The complexity of implementing the new playback architecture in a single program instance is the reason for the move to separate windows. The better user experience is just a side benefit.

Rather a side regression...

Depends on your personal preference of course. There is no objective sense in which either is better. Coke vs Pepsi etc.

Taking away a feature is a regression, period.
Along with the issues on Mac is it a downright bug

Indeed, but it’s a major stretch to call the mundane details of how a particular window is organized a “feature”. Taken to extreme, that’s like saying if you move a menu item from one place to another, you took it away from the old place and that’s a regression. There is no loss of functionality associated with this - just a personal preference as to how you like to switch to switch between scores.

I'd say that, given how many comments we have seen, (mainly in other posts), about the multiple tabs regression that this is not merely a mundane detail but of much higher importance to many people.

Moving a menu is nothing like this. The full functionality of the moved menu is still available. A software regression specifically refers to functionality which no longer works, either because of a bug or because it was removed by a design decision.

Does MS4 offer the split window options of MS3?

No. Got lost along with the score comparison feature. Another regression

And to answer the question you asked originally (but edited it away)
_Can MS4 open the same score in two separate windows, at the same time, and see changes in one of the windows immediately reflected in the other window? (This is not a rhetorical question. I can't run MS4 so I genuinely don't know.):

No, you cannot open the same file twice in different instances either, if you try the 2nd instance opens empty

Being a newcomer to notation software, I’m amazed at the amount of comments this topic has generated (and will continue to generate). Whether using Alt-Tab to task switch between scores or using the mouse to select tabbed windows, I’m just grateful to have found free software that meets my needs.

That's not nice behaviour at all; definitely a significant regression. I often find the split screen mode of MS3 useful for viewing different parts of the same score at the same time.

(I replaced the earlier post because I realised that I was really talking about the split screen mode of MS3 rather than the multi-tab feature. I don't know what happens in MS3 if I try to open the same score in multiple tabs so I'll check it out.)

People do manage to get worked up about the most mundane of details, but it still doesn't make the specifics of which rectangle a scores is displayed within a "feature" that was "lost" in any meaningful sense.

What is a feature that was lost was the score comparison tool, and with it the view that can show two views of the same score at once. Both of those things could be implemented within the context a multiple window model, though, so that's not really specifically relevant to a discussion of whether a give score is displayed within one rectangle or within a different rectangle.

It is not mundane at all and I'd really prefer you to not call it that and with that belittle the request.

But yes, that missing score-cpmparison tool is unrelarted here, just another regression. And one of quite many... most of them listed in MuseScore 3 features not (yet) implemented in MuseScore 4

It's hard for me to see how it could be reasonable be seen as anything but mundane, but I will happily refrain from responding with that observation if you will agree to stop calling it a missing feature. How about we agree to simply call it a "difference"?

And indeed, there are a handful of features of MU3 features missing in MU4, although that this is only a small fraction of the number of MU4 features missiung in MU3. The page you mention is rather deceptive, though, as it includes quite a few things that are in fact implemented even though they weren't two years ago. And a number of things on that list are not missing features at all, but simply changes in the UI for how a given piece of functionality is accessed. So I'm not sure referencing that adds value to this discussion.

In Mu3 a handful request were made to have the option to open scores in different instances. In Mu4 there are hundreds of complaints about that.
Having it as a new feature would have been fine, removing the old way is just bad. Even it understandable given the new playback engine restrictions.
So it is one feature added and another taken away. The latter by definition is a regression...
Yes that document above lists many missing features, quite a few of which meanwhile got reimplemented. Still there are quite a few left.

So it's a non-mundane difference due to a design decision because of the coding complexities required. There's a word for that: it's a regression.

;-)

On the positive side: I learned a new word, and also learned that it has a false friend in German ("mundane" is not the same as "mondän" at all

Knokke-Heist in Belgium proudly proclaim themselves as Mundane. I don't know why, although it is a nice place to visit:
https://woonlookbook.com/2023/02/13/mundane-knokke-heist-for-upscale-in…

Knokke-Heist looks anything but mundane. Perhaps a little quaint in places but very picturesque and well worth a visit. Maybe they mis-translated a similar word to the German one that Jojo mentioned.

Yes, they cleared fell foul of that false friend and mean glamorous.
But we digress 😜

If you want to persist in calling the details of which rectangle your score appears in a “feature”, I will persist in calling it a mundane difference. We can do this all day long, or even all year long…

Multiple tabs was a feature.

As is having separate instances. But trading one for the other is a regression.
Marc calling this mundane is smacking the face of hundreds of users missing it badly.

Sigh. Ok, if you want to keep doing this, let’s maybe keep to a schedule. Mondays you all call it a missing feature, Tueadays I respond that it’s a mundane detail, then we take the rest of the week off. Deal?

As said: smacking the face of hundreds of users missing it badly.

No more than calling it a missing feature is smacking the face of those who choose to make the change (and those who support their reasons for doing so).

Again, if you really like, we can keeping this all year. Or we could let it rest.

No, those who made the change know and acknowlede the shortcommings this brings along and even plan on changing this
Apart from this being a downright bug on macOS in its current form

Feel free to let it rest, I won't

The limitations of macOS are unfortunate indeed, and yes, workarounds for those are being investigated. I wouldn’t assume that means anyone is seriously considering a return to multiple tabs, though. It seems more likely the workaround will be more in the internal architecture, not the UI. Although you never know…

Anyhow, I’m happy to continue this discussion if you are finding it productive.

'returning to multiple tabs' is not the point, 'additionally (!) allowing for multiple tabs again' is.

Sorry, I should have said the return of multiple tabs - that doesn't say anything about whether that return would be instead of or in addition to multiple windows.

But the point I was making is, the known and acknowledged problem is not anything to do with tabs per se. It's an architectural issue involving the use of multiple "instances" of a process versus a single process with multiple windows, which leads to problems on macOS and macOS only. That particualr operating system is currently unable to collapse the icons for these instances or to show document names on the window previews, etc. Theoretically, it would be possible to solve that issue without changing a thing about the MuseScore UI, or indeed without changing anything whatsoever on Windows on Linux. In fact, it could be solved without any change to MuseScore at all, if Apple would enhance their support for multiple instances.

It's still quite impossible to say which of those scenarios, if any, might eventually pan out. Or, as an entirely separate matter, if someone might happen to implement a multiple tabs interface to whatever internal process architecture is implemented.

But the bottom line here is, the request to support multiple tabs is already registered on GitHub. As with any request, once the issue is logged on GitHub, further discussion is not really productive. I'm not suggesting anyone withdraw the request, just that we all probably have better things to do with our time than continue quibbling about it.

Re, "Marc Sabatella • Jan 6, 2025 - 20:27
"If you want to persist in calling the details of which rectangle your score appears in a “feature”, I will persist in calling it a mundane difference."

I'd say it matters a lot which rectangle a score appears in. Just try putting it in the inspector and you might agree. The fact that you choose to relegate the mass of correspondence that this regression caused to being "mundane" seems to show a huge lack of respect towards users; a lack which is only exacerbated by some of your flippant comments in this thread.

A certain well know maxim applies in this situation: "When in a hole, stop digging".

Hello all and MS crew
since humor is finally appearing in this discussion (a bit !), I'll come back to it too... to represent the “slapped” user. In my use of musescore as the big boss - yeah - of an amateur orchestra's scores, whether I'm transposing from a compilation of existing scores - with many and many copying/pasting - or tweaking individual scores, the “windows logic" is a calamity and it didn't take me 24 hours to dismantle MS4.
So Marc... pretending that windows (OS) justifies windows (function) was already humor, I hope! In any case, it's a good thing Chrome, Edge, Firefox and others don't have the same sense of humor, eh?
So let's pray that the “tabs” logic will somehow come back. I think we've well understood the reason for the change, so there's no point in repeating it over and over again... time to listen has come! Github Ok... but it's a bit like a letter to Santa Claus. Now I feel like people are in the street !

The mere fact that I disagreee on a technical issue does not show any lack of respect toward the people I disagree with. But if disagreement equates to lack of respect, then the amount of it being shown toward me here is pretty staggering.

Anyhow, if the only way to feel respected is to not hear viewpoints you disagree with, then that's all the more reason to let this discussion rest.

Calling the request "mundane" is not a technical viewpoint, but an unwarranted and unwanted opinion and shows lack of respect, I'm afraid. In my ears and eyes at least...

To disagree is one thing: to treat legitimate concerns over a regression with such a belittling attitude, (it's just a mundane, non-regression over which rectangle the score is displayed in), deserves to be called out for the patronising nonsense that it is.

If you can't cope with the fact that many users do not find this regression mundane then you should just 'put up and shut up'.

I'm not calling the request mundane; I'm calling the technical difference a mundane one. That is a valid technical viewpoint even if you disagree with it and carries with it no personal judgment of any kind whatsoever. On the other hand, accusing people of being disrespectul or of belittling or of slapping people or of digging holes or being flippant or patronizing or calling one's valid position "nonsense" is not technical discussion at all in any sense whatsoever. It is those comments that are turning this into a hurtful personal diatribe when it doesn't need to be anything but a simple technical discussion. I think we're better than this.

Since the request is open on GitHub, and everyone has made their personal opinion on these technical matters known here, does anyone truly believe there is any point in continuing to belabor this?

You deserve an award for the number of straw men that you have slain in this discussion. Here's the larest one:

Please re-read carefully and you will see that I did not call your position nonsense. I called your patronising, belittling attitude nonsense. There's a huge difference.

Please feel free to post no further nonsense and the discussion will end.

Thank you for the correction to that grammatical detail. The additional personal attacks ("patronising, belittling attitude") is what will hopefully now end.

It wasn't a grammatical correction, it was a fundamental difference in meaning but I am pleased to hear that the additional personal attacks will now end.

I assume you mean you are pleased to report that your personal attacks will now end. In which case, I am pleased to hear that.

Mine! What a hoot! No I meant yours of course.

So, you pledge to continue with your personal attacks? How sad for you. But rest assured, I have no intention of stooping to that level myself.

I have made none. So sad that you are unable to see the belittling nature of you comments, I guess that means we can expect to see more of them.

You probably mis-interprered my mundane, technical comments, but I didn't regress to personal attacks.

At this point is beyond clear that no one has any interest in technical discussion, so I will bow out. Feel free to continue your personal attacks in peace, then, safe from any chance of anything productive coming from meaningful engagement.

Phew! No more nonsense.

See https://musescore.org/en/node/373660, there's another bug with this lack of tabs: Preferences and settings are not shared across the instances.

This is what I raised multiple times already but I feel like my points were consistently ignored. It's a major bug which makes MuseScore unusable for me.

I'm not sure whether that particular issue had been reported on GitHub.

There are several related and intertwined issues (non-exhaustive list):

• https://github.com/musescore/MuseScore/issues/12647 "Use single MuseScore instance for all app windows"
• https://github.com/musescore/MuseScore/issues/19136 "Open multiple files in tabs under a single app window"
• https://github.com/musescore/MuseScore/issues/19188 "Setting 'Continue last session' does not cause all previously opened scores to be opened"
• https://github.com/musescore/MuseScore/issues/19320 "Closing windows behaviour in macOS"