Musescore 4 Multiple Tabs

• Dec 16, 2022 - 07:43

When attempting to open multiple scores in MS4, instead of adding another tab to the preexisting window, a new window opens with each additional score opened. When editing or working on multiple scores at once, this becomes messy. Is this intentional, or is this a bug? If it is intentional, how do I revert to a system like MS3 where I can have multiple tabs with different scores open in a single window and easily switch between them?


Comments

In reply to by jeetee

I hope the new playback engine can be re-architected to allow for multi-threaded use (vs. multi-process use) -- multi-threading is usually far lighter weight than multi-process and then the tabbed approach would be a no-brainer since each tab could be controlled from a separate thread.

Now, I suppose you could architect the whole thing as a large UI shell with tabs to represent open projects, but the open projects themselves are run as headless processes without a "main" window that would show up at the window manager level but rather child windows that can be obtained and displayed by that top level UI and constrained to be within the working "project" area. That way the playback engine can remain architected to run single-threaded within a process.

Anyway, all capable DAWs already allow tabbed projects (I use Reaper) so given that MuseScore is incrementally approaching DAW capabilities, this is certainly something that should be worked on.

In reply to by thomaswb

As far as I know, the current playback system is multithreaded - this was implemented about 3/4 of the way through the beta period. But, that's multiple threads per score. Each score is still in a separate process, each with several threads.

I'm sure separate threads dor each score within a process would be possible, but then you'd be back to the original problem of maintaining the separate audio states for each score.

In reply to by Marc Sabatella

It's certainly not a show-stopper for me, just less convenient to not have all open scores accessible from a tabbed interface.

Maintaining separate audio states for each score should be relatively straightforward (not saying it's trivial though, depending on how modularized the code is for access to the global audio state) using a shared block heap memory holding score-level state that the threads for a given score all access. Given that the playback engine is currently multi-threaded, there must be some synchronization in place to access the shared process global memory for state so replacing with synchronized access to a shared block of heap memory might not be out of reach.

In reply to by user2442

I fully agree, it's a real pain to have each score open in a new window, and I'm shocked that the single tab - explicitly visible in each score window - falsely suggests that multiple scores SHOULD be avaiable on multiple tabs in one window.

also I can't get the program to open a score with a full page or two pages of the score fitting in the window (about 90-100% zoom). this means I have reset the zoom every time I open a score - also a pain. Is there a way to fix this?

In reply to by Jojo-Schmitz

  1. Allow Multiple Tabs to be open in one instance of program.
  2. Allow user to Manually update sounds on Musehub (don't have it running in background)
  3. A Visible save button

To me these are the three most serious issues because they are not bugs they are by design.

Anyway, good luck. I appreciate this software tremendously. I have been using Musescore daily for over seven years? I was one of the first users.
I have been trying to get my overseas friends to adopt it, but Avid/Sibelius is so cemented into the media world that it is going to be a hard sell.

But anyway, I hope a meeting is held and a redesign of 1, 2 and 3 happens.

In reply to by Russell Ferrara

Are you on Windows? If so, how far do you get with the procedure? It's certainly more fiddly than a normal installation and I made the guide partly as reminder to myself. As mentioned above, 3.7 is an unofficial version so t can't get released in the usual manner. The last official MS3 was 3.6.2.

Yes, you do have to jump thru hoops but once you done so a few times, you get the hang of it and it only takes a couple of minutes. Typically, I only update when there's something new that I'm interested in. I don't install every single update.

If you are on MacOS then there can be different issues and a MacOS user may be able to help.

[Edit] Thanks Jojo, you pipped me to the post again. 😀

I don't know which platform the OP is using, but on Mac, opening another document opens another instance of MuseScore. I have not seen anything like that in many, many years of using a Mac.
Sorry for all the hard work that went in 4, but I'm sticking to 3 for now.

In reply to by gr3p3

Then it is even more of a problem than I thought. Not only a new window, but even a new instance.

This means that I am not going to use it as long as this will be the case.

MuseScore 4 has the potential to be absolutely stunning. I really hope this will be repaired.

In reply to by jeetee

Thanks for the link. I read through it and realize now that the awareness of the problem within the team is already deeper than I knew. I also understand that quite some code might need to be rewritten and that would take time. I am happy that 4.x is named as a potential release point in the discussion.

I will now stop complaining...

It looks like at the top where the tabs were in muse 3 is similar to muse 4, i really hope this gets updated, i would rather not have multiple windows open when I'm comparing score.

This is prohibitive for me as well. I'm staying on version 3.0. Regretfully because the new version seemed promising. Hoping that this problem will be fixed in a future update...

I am in a chorus and I practice with a few open scores, switching back and forth between songs, changing tempo and vocal mix as I learn my part in each. That is impossible to manage with all those instances, all those mixers, all those play panels

In reply to by bobjp

Those multiple windows still use the same instance of Word loaded into memory. However, the downside of this is that: if one window crashes word then all the windows crash since they are sharing the single instance.

This can happen with Excel VBA so it can be preferable to deliberately choose to run multiple instances of the program to give some crash protection. I guess that the same is possible with Word VBA.

Launching an entirely separate instance of an application is very uncommon on the macOS: I'd go so far as to say that it breaks the design philosophy of the programme. Don't like!

In reply to by bobjp

The design philosophy that forces you to have all documents open in a single instance rather than the equally convenient multiple instances I guess. ;-) A chacun son goût.

The real problem with Musescore in multiple instances is that they don't inherit settings. Set up a workspace how you like it and create a new score. The new instance uses the settings from before you set up your new workspace. You have to close Musescore, re-open it and only then can you clone new instances with your new workspace settings

Just adding my voice to this.
If there is an option to disable the sound engine completely just to be able to have different scores within one window, I could deal with that.
On Mac, Musescore opens another application named identically--so cmd-tabbing between these Musescore apps doesn't even let you know which score you're tabbing to.
It does seem quite clunky and counter-intuitive.

Switching between multiple windows when using a single app could be annoying. I am switching back to MS3 until the multiple-tab feature comes back in MS4.

In reply to by Jacek Gajek

If you create a virtual desktop on Windows 10 then Alt-Tab is constrained to the active virtual desktop. So, put MS instances onto the same virtual desktop and Alt-Tab will switch between scores. With many apps the taskbar will give an indication of the app's contents, e.g. filename, (score name).

I think for the people evaluating user feedback it would be helpful if everyone who has mentioned their dislike of the missing tabs here would also explicitly state why they think tabs are important for their use of MuseScore (if they haven't already done that.

In reply to by RobFog

After experimenting with it for a while, I have to say I like the new system with one score per window, and tabs for the different parts. (At first I thought tabs had disappeared altogether, but they are actually being put to a different use.)

What I would find very difficult to live with is multiple instances of the app existing if I am editing multiple scores. In any case on the Mac. But it seems the team is aware of that and is working on a solution. If that is implemented my voice actually goes to keeping windows-for-scores and tabs-for-parts.

In reply to by user2442

Running multiple instances of an app can have advantages. I typically run multiple instances of Excel whenever there is any VBA involved as this gives some measure of crash protection. If you use a single instance (loading multiple files) then a crash kills all the Excel windows and you lose all changes to all loaded files.

So maybe, with MS4 being so new, it is more likely to crash in its earlier releases than later on and, therefore, multiple instances could prove to be a score saver.

In reply to by yonah_ag

Maybe on Windows, but on the Mac multiple instances are very inconvenient. You get multiple identical icons in your system tray with no way to know which icon hides which score. Same when trying to switch between instances with Cmd-Tab (Mac version of Alt-Tab) - no way of telling to which score you are switching. That gets very annoying very quickly.

As to crash protection: you can set autosave in increments of 1 minute, starting with 1. So not too much of a problem, I would say.

In reply to by user2442

One of my pet hates is autosave! It's a waste of disk i/o and my mechanical hard disk is on the way out. Autosave wreaks of dodgy software. If software is stable then I much prefer to save manually.

There are clearly different preferences amongst users on this issue. Maybe it depends on how many scores you tend to have open. I only have 2 at most, so I would easily know which I am switching to but I can see that this could be annoying if you have a lot of scores open.

I think that it's good to see MS4 launched now, as it has been eagerly anticipated, and leave a resolution to a future update, rather than delay the release for this feature.

In reply to by Marc Sabatella

I'd rather not give my aging hard disk that extra hammering. Once I'm confident that software doesn't crash then I don't use autosave. I know that the current trend is to save after every keypress, (e.g. Google docs), but this just seems really paranoid to my old fashioned mindset.

For disaster recovery I use a backup system.

In reply to by yonah_ag

No version of MuseScore has ever been immune to crashes. And the autosave interval is only three minutes by default and can be customized to be less. If your hard drive is so unreliable that you don’t trust it to save every three minutes, it has far worse problems than can prevented by disabling autosave!

In reply to by Marc Sabatella

My PC has trouble booting but otherwise seems OK. There's nothing on it that I can't easily recover so I'm only vaguely looking for a new one. Maybe I can pick one up in the January sales - but I still won't use autosave. I have only had a single crash with MS3.6.2 so it's very reliable for me. I'll wait for MS4 to bed in before installing it.

In reply to by RobFog

I often want to make a different version of score so I need to have both windows (old score and new) easily accessible and switch between them. With Mus4 the way to swap between windows now has to be cntl-tab, but that swaps between all currently open applications, and on my machine there are a lot of those. I know I can also use the mouse to click on the corner of a window. But keyboard is faster.

Aquedelta, Dec 16 2022 : "how do I revert to a system like MS3 where I can have multiple tabs with different scores open in a single window and easily switch between them?"

Treat your desktop as a single window and use keyboard shortcut (Atl+Tab on Windows) to switch between instances of MS4 easily.

Unfortunately this is a show-stopper for me too... Thankfully I store my files on a versioned cloud otherwise I would loose my scores. (MS 4 and cannot save files in a MS 3 compatible format).

In reply to by Jacek Gajek

Hmm, I'm somehow still not understand how pressing Ctrl+Tab is more better than pressing Alt+Tab, or clicking a tab within the MuseScore is better than clicking the taskbar icon. It's functionalllu the same, better even in that Alt+Tab nicely switches back and forth between scores. Can someone please explain more clearly what they feel they are actually losing, as opposed to simply needing to press/clicking a slightly different button than before?

In reply to by Marc Sabatella

There is a reason why browsers started to use tabs. Alt+tab cycles between all apps. So it's not reliable as it can take you to a web browser or PDF viewer.

Also on Windows you don't have a visual feedback because all instances of app are hidden under the same icon so you don't really know which scores are currently open.

It's not only about UX, it's about loosing a lot of functionality, for example you cannot customize palette if you have multiple instances of app. You change a palette in one score but cannot use it in another. Same with everything.

It's not only about functionality, it's also performance. In MS3 opening a score is instant. MS4 it takes several seconds. Imagine that I have 30 single-page scores which I want quickly review before a gig (a real-world use case). In MS3 they can be opened in a few seconds (select 15 files in Windows Explorer and press Enter, repeat) and I can cycle through all of them with ctrl+tab. In MS4 it would take ages and took 9 GB of RAM with no way to linearly cycle through scores.

In reply to by Jacek Gajek

FWIW, I do understand and sympathize with these special concerns. But so far no one has found a way to solve the more fundamental problem of needing different playback profiles for each score with these other desires. It's a difficult technical problem that so far none of the core team nor any of the community members who contribute to the development have devised a satisfactory solution for. For most cases, Alt+Tab and selecting from a menu work very well.

In reply to by Marc Sabatella

If you use Window 10 virtual desktops then:

• Pressing Alt-Tab is constrained to the current virtual desktop
- so put your instances all on the same virtual desktop and name that desktop "Musescore" (see pic)
• Separate instances can be seen in the Taskbar with the start of the score name, (visual feedback 1)
• Pressing Windows-Tab shows all your instances in a mini-view, (visual feedback 2)

MultipleMS.jpg

This doesn't solve memory usage problems etc. but can help with easy switching

In reply to by Marc Sabatella

Well I can cite Elon Musk "5 steps of design" here
1. Make the requirements less dumb.
2. Delete the part or process.

Why do you insist on keeping the "needing different playback profiles for each score" requirement? Seems to be a rare edge case for me and if somebody needs that then they can launch a separate instance of app anyway.
Seeing how many features we loose due to this requirement (basically all customization of workspace) it really needs to be groomed again.

In reply to by Jacek Gajek

That's a good question, but I think you probably underestimate the value of having different instruments loaded for different scores. After all, you might have a piano score in one window, an orchestra in another, choral music in another, etc. But indeed, it would be great to find a solution,. So far, people have tried but not succeeded. if you're saying you have expertise in this area and are volunteering your service to help in the spirit of open source cooperation, great, I'm sure the team would welcome your contributions!

In reply to by Jacek Gajek

Currently, yes, if you have two scores that happen to use the same sounds, those sounds are loaded for each score. The background process you mention is just a small installer, it's not actually part of MuseScore itself nor is it meant to be (it also works to install other programs from the Muse Group).

As mentioned previously, if you have technical expertise that youbeleive would allow you to solve the problems that have thus far eluded the professional software developers who bui,t this system, Ithen I am sure they woould welcome your input! However, this forum is not a good place to contact the developers - instead see Contribute / Development in the menu above. I recommend starting with the Discord channel and explain your design proposal there.

In reply to by Marc Sabatella

I want to warn against using this “small program”. It is called MuseHub and very easy to use, but it installs a service with unlimited acces on your computer that runs permanently and which could potentially compromise your system and expose it to external parties.
Instead, you can use the direct “Download without MuseHub” link on the MuseScore download page.

In reply to by bobjp

@bobjp:

Thank you for asking. The subject deserves a impartial, fact based discussion. Sorry if this is lengthy, but I feel I need the space to not seem "just claiming" but actually to explain why I think the way I do.

I invite everbody to either refute or support my position with factual arguments. I believe in free discussion, and I would be very happy to be proven wrong. I will not be afraid to withdraw it and apologize, should that happen.

You ask for a security report on MuseHub. Nothing would be better than a successful security audit by a reputable third party. Such an audit does not exist as far as I know, and to execute it one would ideally need source code access to the app, which is impossible without cooperation from MuseHub, since it is closed source.

But observations on its behaviour can be made, have been made, and have been reported both on the MuseScore forum, as here, and on the MuseHub forum. They give me cause for concern.

Many of them are from sources that I consider reliable, both from the wording used and from what they report. Some reports I have confirmed on my own machine. Below I will summarize a few. My own background is professional software engineer, with good knowledge especially on Linux and MacOS.

I would welcome any contribution on all systems, but especially on Windows, either to support or to refute my concerns.

Now to the issue itself. Since the problem lies in the technique, I will necessarily have to make a few technical observations. I will make them as accessible as possible, without oversimplifying.

First the notion of "root access" that comes up frequently in the reports. "Root" is the term used in Linux and MacOS for the "superuser", that is roughly the same as the system administrator: the person who can install applications, access and modify each and every file or folder from any user, and indeed modify most (on MacOS) or all (on LInux) of the critical system files. If the superuser has bad intentions, he can make the machine crash, expose all information on it to outside parties, or have it take part in mass attacks on critical services. Or report on your movements, if installed on your laptop, or anything else that a computer can do.

If a process (program) is "owned by root", it means that it can do everything the superuser can. The deepest layer of the OS consists of processes owned by root. That is necessary to perform critical tasks. These programs are part of the OS and are provided by Apple or Microsoft, or come with your favorite Linux distribution. They are protected by layers of security, and can never be touched (modified) by ordinary users or by programs ran by them. Only an administrator or another root owned process can access them. An ordinary user should have no need for them. They will run on his behalf when necessary, without him either knowing it or controlling them. That is to protect the integrity of the system from harm, committed either unknowingly or on purpose..

Now it has been reported that MuseHub installs a root owned process. I have confirmed that this is the case on my Mac. To see it running, enter (in a console window):

$ ps aux | grep -iE 'muse|hub'

This gives:

root 688 0,0 0,1 34338016 25116 ?? Ss 1:54 0:00.36 /Library/PrivilegedHelperTools/com.muse.museservice

This confirms that it runs with root privileges. It also can be observed that it is running all the time, even when MuseHub has been closed by the user.

It is considered bad practice, and a security risk, to have programs provided by third parties running as root. Three reasons are:

  • The author could have bad intentions
  • The author could, in good faith, have made a programming error that compromises the system
  • A malicious third party could use the program as a backdoor into the system to wreak havoc, as described above. And don't think that there are no parties constantly seeking access to any computer they can. This is especially the case when the program is open to communication from the Internet, which MuseHub is, since it is open to bittorrent traffic.

Why does MuseHub thinks it needs such powerful access? I do not know. Its apparent function are:

  • To regularly check for updates on software (MuseScore, Audacity, ....) provided by the Muse group, and to download those. The same for other content such as MuseSounds. A non-root program could do that just as well.
  • To install updates without user intervention and silently, after download.

The only reason it would need root access is the silent install, since that requires writing to the system wide application folder, for which you need root access.

The alternative, which virtually all other programs use, is to notify the user of new versions and let him do the installation himself. A very small price to pay for avoiding giving indiscriminate root access to a third party. (And in fact my preference, since I might decide I do not want a specific update.)

This is the core of the argument. I may very well not have addressed all your questions, in which case I hope you will come back with them. As said, any outcome of the discussion based on facts is welcome, and should it be determined that there is no cause for concern after all I will be a happy person. If only because that would give me safe access to the beautiful MuseSounds libraries.

In reply to by jimfoster

@jimfoster:

It is interesting to me that you posted this in the middle of a thread that has nothing to do with the Hub. Forum protocol suggests that this type of post should be a separate topic. This alone makes your post suspect. Not because I doubt the veracity of the content. Or that you truly believe it. The Hub Service is running on my Windows computer even after I close it. I don't know for sure, but I suspect that many other services are running that have root access, also. It's possible that someone with malicious intent could hack into any of them at anytime. It's also possible that might never happen. Once the Hub has been used to download the sounds, it can be uninstalled. At least on Windows. And then re-installed later. If you really want more people to join in, start a new topic.

In reply to by jimfoster

@jimfoster
Whilst your info should be in its own thread, it is indeed concerning that a 3rd party piece of software requires such a high access level. In mitigation, the devs have no history of malpractice so I doubt that there is any malicious code included. We just have to hope that it poses no security risk from hackers.

In reply to by bobjp

I summarized the arguments made on this forum why MuseHub should be considered dangerous. I politely asked them to look into it and take action. I posted a link to the entry on this, the MuseScore forum (https://musescore.org/en/node/339231).

With "100 % working" I just meant that this link, https://musehub.zendesk.com/hc/en-gb/community/posts/8450771193629, was working at the time I posted it.

UPDATE: As of today, January 4, the entry has been reinstated.

In reply to by user2442

I haven't as yet been able to see if the Hub runs with root access on Windows. I quit the Hub so it doesn't show in my taskbar any more. The exe. service is running on port 7364. But, as I already said, there are other services for closed applications running on various ports above the 1025 mark.
So far I can not verify that the Hub is an actual problem. You say there is potential danger. I can't really verify or deny it. So I can only leave it alone, because I can't see the need for any action on anyone's part. A poor argument would be that just going on the internet is dangerous. I wouldn't accept that argument. So what are we to do?

In reply to by bobjp

I'd say we need solid, undisputable facts more than anything. There is a lot of disagreement at the moment, fueled by incomplete information, and a factual investigation should help.

I propose to open a new topic with title "MuseHub -- what does it do and can it really cause harm? The facts." or something like that. I think the combined knowledge of forum users should give us really fast solid ground to stand on and make us know if there really is a problem, if so on what platforms, and what, perhaps, could be done about it. (And no, the answer cannot be "give up on internet"...)

Would you agree?

In reply to by yonah_ag

And as explained previously, the place to contact the Muse Hub developers is via their Zendesk site. Feel free to start a new thread here on this community-oriented site to reach a consensus before reaching out to the developers, but when you are ready to contact them, you will need to do so through their Zendesk site.

In reply to by Marc Sabatella

@Marc Sabatella: Coming back to this point: I did indeed make a posting to their forum, see https://musehub.zendesk.com/hc/en-gb/community/posts/8450771193629-Muse….

Some discussion followed, with others chiming in. In https://musescore.org/en/node/344865 you can read that the developers have fallen silent after well-argued concerns had been posted. This leaves the matter in limbo and unresolved. Will you be able to help?

In reply to by yonah_ag

@bobjp, @yonah_ag,

In retrospect it would have been better to move the explanation to a separate topic and put a link here. My bad.

However, it was an answer to "please provide proof" from bobjp and as such I do not see what there is "suspect" about it, as he says.

My original post was a simple warning as a reaction to an earlier post in this topic where, undoubtedly with the best intentions, the use of MuseHub was presented as a thing of course, without any warning about the possible dangers that come with it. Dangers that have been signalled many times in other topics on this forum.

I think such a warning is not out of place. Many users, especially of this topic, might not be aware of the problem, and as such I think there is nothing wrong with putting in a warning.

If bobjp would be interested to know what could be true of "many other services are running that have root access" on his machine, he just has to ask and I will argue that that is very likely not true in the sense he seems to mean.

And also that even completely uninstalling MuseHub after use might not take away the risk. In a separate topic this time.

In reply to by jimfoster

I have just checked my Windows 10 setup to see which services are running with Local System access. The only such services running, which are NOT part of the Windows installation, are from my antivirus software.

There are 3 Google services with Local System access but these are not running, even with Chrome Web browser open; and there is a Bonjour service which I disabled some years ago so this is not running.

So it does seem odd that MuseHub should need system wide access.

In reply to by Marc Sabatella

I don't see why there should be a "difficult technical problem" (https://musescore.org/en/node/338084#comment-1160613). If they had made a normal midi interface for MuseSounds these problems would never have occurred. As it is, they have forced MuseScore to build an awful proprietary interface to their lib. With all the problems we are now facing.

Why did they, I wonder? To create a lock-in situation for anyone wishing to use MuseSounds? Certainly looks that way. Doesn't speak well for their intentions, and certainly not in the spirit of what's best for the community.

In reply to by johnweigand

If you have a solution in mind, I'm sure the development team would welcome your PR that solves it!

But for the record, no, using a "normal interface" for Msue Sounds would not have changed anything about this. The only thing it would have accomplished is rendering Muse Sounds much less realistic. The reason MIDI wasn't chosen is that it is far too limiting, which is why soundfonts can never sound as as good as Muse Sounds and why VST's can come close only through the use of hacks like keyswitches but even then fall short of the capabilities of Muse Sounds.

The interface is not intended to create a lock, BTW - it's going to be published soon as open source, so anyone can use the same interface.

In reply to by Jacek Gajek

@ Jacek Gajek You said: "Also on Windows you don't have a visual feedback because all instances of app are hidden under the same icon so you don't really know which scores are currently open."
Right now I have 12 full orchestra , multi-page scores open in MS4. If I scroll over the icon in my taskbar, I see a preview of all 12, including titles. If I scroll over the previews, I see the first page of each score full screen.
I won't even go into how odd it is to use scores (rather than some kind of copy) to look at for most any reason other than editing.
True, MS4 takes longer to load than MS3. That's because it does more. But it sounds to me like you don't need MS4. Great. No problem.

In reply to by yonah_ag

I would never do that in any real world situation. I just did it to see what would happen. And I only did it with 12 scores because that is my full MS4 folder. It maxed my CPU, but I still had ram. This computer is about 8 years old, and doesn't meet MS4 specs. Dual core i5. 8GB ram. 1TB SSD. Oh, and an old Diamond Sound Tube as a usb audio interface. Cost about $20 back in the day. Playback of loud full orchestra scores is fine.

In reply to by bobjp

Impressive, especially as this is such an extreme example. It doesn't look like the multi instances of MS4 are over taxing so I would've thought that there are higher priority issues to address than working on a single instance multi tabbed interface.

In reply to by frfancha

I disagree - paging requires a fair of guesswork, and in a single-instance app, there is no way for an OS to know which page sare associated with the current score and which are associated with other scores. So it will not be able to make optimum choices compared to swapping processes - which in any well-written OS is very efficient.

I'm not saying there would necessarily be a noticeable difference, but I am saying, the mere fact that sounds are loaded into multiple process is not going to be a problem in practice, because any loss in swapping processes is likely to be more than offset in being able to keep the right pages in memory. Only if you spend more time switching tabs than actually working on a score would it be the other way around.

In reply to by frfancha

Re: frfancha • Dec 31, 2022 - 20:49
"so no, it is definitively not more efficient to use several processes"

I think that bobjp's test shows that the efficiency, or otherwise, of multiple processes is not a performance problem in the real world, provided that the CPU is not constantly flat out. It would be interesting to know how many scores needed to be closed to bring his CPU back to 50% or less, especially as his test was on a relatively low spec PC.

In reply to by yonah_ag

Tested on a dual Xeon E5-1620 @3.60GHz with 16GB RAM, OS: Ubuntu 22.04.1 LTS, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-223472159, revision: 5485621

The basic program takes about 300MB RAM and each score (even if it is empty) about 200 to 300 MB. No problem if you have enough RAM but this is way more than MS3 used and, for some people, will lead to swap file usage which will really slow things down.

Fortunately, you can buy some seriously powerful ex-corporate PCs on eBay (I am replacing my current system which is 10 years old with a 4 year old machine because the old one has a physical problem with the ethernet circuitry). Or, depending upon your machine, you might see a benefit from adding some RAM (and that might help in other programs, too).

This is terrible. Tabs are the way to go, and it's the expected behavior for virtually all software; even my TeX editor works with tabs and doesn't put up a fuss. I understand that it's a one step forward kind of deal, but (edited) nope, Stage Manager doesn't work; the OS treats the application as separate instances, so I am sending the various windows to the background entirely.

In reply to by bobjp

No it isn't.
Switch windows shows you Word instances only, not everything.
And it is a list of names, taking less space on screen than the task bar hover, so you can immediately spot the correct one even when many of them the are opened.
And again you get options to arrange these Word windows on screen.
Bottom line, Word doesn't use tabs, but offers all the same features tabs would.

In reply to by bobjp

But Pages does. And going from tabs to away from tabs is not how this should behave. I’m particularly sensitive because of the way running multiple instances of the program works on macOS. It’s poorly conceived.

It’d be one thing if the default was a new window, but it’s just not even possible to change this. Stupid, stupid, stupid.

In reply to by bobjp

Because you’re not listening and neither were the developers. They still aren’t. You are reflexively defending this all while pointing to things that never had tabs.

I’m also entitled to my opinion.

It is, indeed, bad, as EVERYONE complaining has been pointing out. This simply doesn’t work as expected, and while I appreciate some of the improvements, the software needs to work as expected, and the changes shouldn’t massively disrupt how users work. That is indeed a poor conception, and you’re not obligated to respond so if you don’t want to listen, so I think I’m done here.

In reply to by luntastonemason

I'm not defending anything. Just making observations. I hear (as in listening) all kinds of statements about the lack of tabs being bad. I never used tabs in MS3, so it makes no difference to me. But I would never make that decision for you. Bad for the way you work? Sure. Bad in general? Not so sure. You think the developers don't know how important tabs are? There may well be perfectly good reasons why there are no tabs. They may well come back. We may never see them again. Who knows.

"the software needs to work as expected". So it doesn't work as you expect it to work. That makes it a bad program. Yes I know lots of people use tabs. I am especially impressed with the organist that has 130 tabs open at once. But he doesn't really need MS4 for that.

Everyone uses the program differently. For me there are many,many things far more important that, in my opinion that need to be fixed first. But I forgot. You've decided we're done.

In reply to by bobjp

Other things that Word does well despite being multi-window: change your ribbon in any of the Word window (+/- customize your MuseScore palettes), all other Windows immediately have your new ribbon. Or change an option, it is applied to all opened windows at once as well.

I also want to use multiple tabs. I often create a few different versions of a composition/arrangement at the same time so that I can see all my options and then decide which one I like best. I frequently switch between tabs. Switching to a whole new window is a huge pain. Please change this!

In reply to by Oded Violin

As per Martin Keary (AKA Tantacrul) the Save Button "is a thing of the 90s" and therefor got removed...
(Don't dare to critisize that or any other decision or he'll harrass you until the end of time for "defending rubbish ideas", no joke, believe me, I know what I'm talking about here)

Shortcut Ctrl+S to the rescue

In reply to by Oded Violin

@Oded Violin
It's not stupid but I totally agree with all your other points, especially on adding an option. Personally, I'm a Ctrl-S type but I know that a lot of people prefer to have a save button in their apps.

I wonder what MS would do in the "not-going-to-happen" iPad version, where you can't press Ctrl-S. "Sorry, you can't save, it's too '90s!" ;-)

Some people are talking here about tabs or not, new windows, etc.

It would be fine if it weren't tabs, but different windows in the same instance of the application. I don't have a problem with different windows like you get in Word, Pages, Numbers, etc. as opposed to tabs, but the problem as I see it is that there are standard macOS shortcuts to switch between open documents in a single application. I can use cmd ~ to live cycle through open documents in a single application easily. I do it all the time. Tap until the document I want is frontmost. No guesswork. Some would argue this is better than tabs because you don't have to use the mouse/trackpad to get to any particular document.

Or, I can use the Window menu or the Dock icon of the application to see which documents I have open and select the one I want. But, MuseScore has no Window menu (I don't know if the Apple HIG says they should. MuseScore 3 doesn't have one, either) so that option is out. When I tried the Dock menu, I got weird results. Sometimes it switched application instances, other times it did that and resized the window for some unknown reason.

Some have suggested using cmd-tab (Application Switcher) to switch between MuseScore instances. The problem with that is while cmd ~ keeps you in the application and lets you live switch, cmd-tab only shows you the application, not which document you might end up at. You can also easily end up in another application if you slip. Cmd~ lets me go, "oh, not that one, maybe the next one" but cmd-tab switches the order of the apps, so if I go to another app and want to go back to MuseScore, the order might have changed or if I've been in several apps the different ones are moved around. Frankly, it's just not how we are used to working on macOS.

I understand that there is a technical reason they made this choice. I am grateful these guys have been developing MuseScore and very happy to use it over the paid apps, each of which I have a reason I don't want to use. But I really hope they find a way to not need to open multiple instances of MuseScore 4 soon, because I really struggle with it and I've found myself preferring to stick with MuseScore 3 for now.

In reply to by jmuscara

jmuscara wrote I understand that there is a technical reason they made this choice. I am grateful these guys have been developing MuseScore and very happy to use it over the paid apps, each of which I have a reason I don't want to use. But I really hope they find a way to not need to open multiple instances of MuseScore 4 soon, because I really struggle with it and I've found myself preferring to stick with MuseScore 3 for now.

Ditto to that.

I also agree with jmuscara's second and third paragraphs. Particularly where he wrote: Frankly, it's just not how we are used to working on MacOS. and I can use cmd ~ to live cycle through open documents in a single application easily. I do it all the time. Tap until the document I want is frontmost. No guesswork. Some would argue this is better than tabs...

Command ~ is also my way of cycling through the app's open documents on MacOS. Very clean and easy. And it keeps a stack of the most recently viewed, so it's simple to toggle between the last two viewed or edited documents.

I rarely use the Window menu but it can be very handy too.

MuseScore 4 is massively better in almost every way than 3 except for this separate application, it is a real pain, and also makes loading a score really slow if you already have MuseScore open, instead of near instantly. Hope this can be fixed in the future.

Yep, I work on many scores at the same time for website content so the tabs option was awesome. It's not a huge deal though. I use Logic for example and you have to have separate windows for each project so it's just a case of getting used to it. Sad to see screen shot gone too because I used it tons for cutting up charts to add them to tutorial videos.
By no means complaining though for a free open source app it's incredible, I've used them all and Musescore is the best notation app by far. So easy to use and intuitive. You can't believe the amount of work that's gone into developing MS4, hats off to the developers!

I really hate the new behavior. It's also awful because it bloats the memory usage. Looking at my tasks, having two windows open with 1 sheet in each, the second process takes a whole other half Gb of memory. That's really awful for multitasking on the computer. Often I'll have something open while I'm working on a different thing, and flip back to it. Currently musescore3 is much better for that use

Yeah the nonexistence of this feature is the main thing keeping me using Musescore 3. And honestly it's a showstopper for me, it sucks that this feature isn't in Musescore 4. The devs should add it in ASAP imo.

In reply to by Trolligi

Can you explain more about what prevents you from using this? I honestly don't understand - most other major applications also display separate documents in separate windows.

As explained elsewhere, it's really just not feasible to force all documents to live in the same process any more, since that would go back to the dark agers fo also forcing all scores to use the same sounds. Barely tolerable if all you have is soundfonts, but in a world of VST and Muse Sounds, it would not work at all.

In reply to by Marc Sabatella

You are probably on Windows, where you wouldn't notice the difference. On Mac it is a major issue.

Having separate windows is not the real usability issue. In fact, I would like separate windows for individual scores. But the root problem her are separate processes for each score.

On the user interface side, this clutters your dock - the place down on the screen where your apps show their icons. All MuseScore instances running, one for each open document, have an icon here and there is no way of telling which icon refers to which instance. If you want to go to another document, you have to pick one of the identical icons and hope that it is the right one. (There is no indication which one you are looking at if you hover over the icon, as on Windows.) If you work on a number of scores concurrently, that is practically unworkable.

On the implementation side, there are really different instances of the app running. That can take up a lot, sometimes too much, of system resources. Also, they all have their own settings - if you change one, it doesn't reflect on the others. Usually that is not what you want.

I don't agree with your estimation that forcing all documents in the same process would necessarily force all scores to have the same sounds. That is currently the case, due to some architectural decisions made regarding the way the sound libs, in particular MuseSounds, are accessed, but there is no reason to think that needs to be the case.

I think with a bit of redesign of the architecture that restriction could be lifted. That redesign would have to take place both at the MuseScore side but also on the MuseSounds side. I do not think it would be terribly difficult if looked at in the right way, and most of the working code could remain as it is. I am a software architect and would be happy to contribute to such a discussion.

In reply to by user2442

Indeed, this limitation of macOS is a drag, but I don’t see how it would be a deal breaker. Cmd+Tab still works normally, does it not? And surely having incredibly superior engraving and playback or more important than the number of icons on your dock?

It’s not an “estimation” that placing all scores in the same instance means using the same sounds. Its an implementation reality. That’s the entire reason for the change. In theory one could fake this by unloading and loading sounds every time you switch scores hit it would be horrifically slow.

But if you believe you have found a solution that all the developers
missed, your code contribution would of course be most welcome !

In reply to by Marc Sabatella

If Cmd+Tab would work, there would be no issue. But it has the same problem as the dock: you can't tell to which score you are tabbing.

The "estimation" under discussion is not about how things are now, as you seem to think. I know how they are. It is your apparent idea that forcing all documents in the same process would necessarily force all scores to have the same sounds. I don't think that is the case. It is a result of architecture decisions, that I think could have been made differently.

Of course I have no ready code to solve the issue. That is not how software architecture works. Solutions can only be found in constructive and open dialog. With open minds on all sides, a solution can be found. And I am willing to participate in that.

In reply to by user2442

Wow, I didn’t realize macOS didn’t show document names - that’s crazy! Hopefully someone has complained to Apple.

As for what you think is the case abint the code and architecture, as I said, if you’ve studied it and think you’ve found a solution the developers all missed, they’d love to hear about it! but as it is, I see no reason to assume it is other than what they have all concluded.

In reply to by Marc Sabatella

Again, as I said, I have no solution ready. I have no insight in the architecture, half of which is in closed source anyway. But an architect would need no access to the code to assess the situation and find alternative ways.

First step would be to find out what the actual setup is, and why that implies the current situation. That can only be achieved through dialog with people who know the code and the architecture. Only then one can start thinking about alternative ways. I would be very surprised to find that impossible.

In reply to by Marc Sabatella

As an observation, take Reaper for example. I can load multiple projects there in a tabbed interface each with a completely different set of VSTs (or a mix of shared and different VSTs).

I see MuseScore being very analogous to a DAW with each instrument being a MIDI track feeding through to one or more VSTs (instrument and optional effects). If other DAWs can present a tabbed interface for projects, it doesn't seem an unsolvable problem.

But (as I've said before), for me it's a minor nuisance that once I get more comfortable with it'll get better.

In reply to by thomaswb

The multi-tab problem isn't a "Mac only undisplayed file name" issue.
It is an issue for all platforms that "global" settings (palettes, options, ...) changed in one instance aren't effective in other ones without closing and reopening them.
And that "last closed instance" wins for the saved settings.
With that into consideration the correct way to change settings is to have one opened instance only, make your change, close and then only (re-)open the documents.
I hope you realize this is an inconvenience.

And I don't know why the chrome example is dismissed so easily. MuseScore needs a different process by document for sound? Well guess what Chrome tabs have all their individual process.

In reply to by frfancha

Indeed, there are other minor inconveniences caused by this necessity. I am not saying anyone loves everything about the current solution, but until someone with more advanced technical than any of us (including the developers) have proposes a better one, it's what we have, and minor nuisances aside, it's still light years better than what existed before.

Ad for Chrome, again, Chrome doesn't have to deal with VST or Muse Sources.

In reply to by Marc Sabatella

Yes, Chrome is probably not the best example but existing DAWs that do handle VSTs, audio input and output, and provide a tabbed interface for multiple projects is a perfect example. And, also yes, I really do appreciate the new capabilities of MS4!

I really wish I had the bandwidth to dig into the new sound engine code (if it's even all viewable up on git, that is). Because my sneaking suspicion is that it must be using process level global variables for its operation which is why each score needs a separate process. Encapsulating those into thread local storage instead is a doable thing, the scope of which depends on how modular the access to those variables is to begin with.

I understand why people are frustrated with this. Musescore has advanced and it's working more like a DAW or Video editing app with VST plugins and other sound options so opening a new file is like opening a new video or audio project which is more demanding on the system where as before you could switch between projects on tabs and they would load instantly.
I think the best and easiest solution would be to have an option in settings that would disable the advanced audio features and only run soundfont if people didn't want all the fancy stuff and this would allow for tabs to be used once again, kind of like a simple mode and advanced mode option.
It's incredible the amount of work gone into making these new features but unfortunately I don't think most people really use them that much unless you're writing big scores etc. I think most of us are just writing out lead sheets and don't need to use plugins.
Either way it's still the best and easiest to use notation app I've ever used and it's free and I'm very grateful for the developers that put time into making it.

In reply to by philwil20121

I think the best and easiest solution would be to have an option in settings that would disable the advanced audio features and only run soundfont if people didn't want all the fancy stuff and this would allow for tabs to be used once again, kind of like a simple mode and advanced mode option.

I find that an excellent suggestion, until the issue has really been solved. People spend most of their time on MuseScore editing scores, not generating sound files. Only if you are done editing, you could switch to "advanced" for a moment.

Of course, in the "simple" case one would want the single process instance back or nothing would be gained. Some work would have to go into that, but not too much I think.

Maybe even better, and even simpler: go back to how it was and only allow basic sound fonts. No problem to implement. Create a separate "mode" for generating sounds with MuseSounds or whatever, on a per score basis. You can configure what sounds you want in the normal editor, only thing is you can't hear them until you switch to "sound generation". That will be for the current score only. At that time the rich sounds are loaded as indicated for that score, and you can hear them and save the audio file. Of course, in that mode you can further tweak your sound configuration and that would be retained with the score if you go back to editing. You could even allow editing in this mode, but only on the score being worked on. The others would be "frozen" during sound generation mode, or rather, for them no sound generation would be possible at that time.

So, the work flow would be as follows: work on any number of scores, in a single process instance. Multiple windows, one for each score with tabs for parts are fine. When you want to work on the full sounds for a score, switch to sound generation. That works for that score only. You can continue to edit it, and hear the result with full sound quality. When you are satisfied you go back to full editing mode where you can switch between scores as much as you like.

I'm probably not the right one to comment on this but my main tool engraving music is Lilypond together with Frescobaldi on a Windows OS. In Frescobaldi you can have as many scores open as you want in a tabbed window. One problem with this is that at some time you won't see all tabs at once and have to scroll to see them. The second problem is that the tab get narrower and narrower (down to 8 characters I think) and then you cannot see anyway which file you are searching for. So, even if I shorten the file name to Vi1 but reuse this in more than one piece, you get two instances of Vi1 in the tabs which is not very useful.

Ok, this can be solved by a smart naming convention, but what is more important for me is to have more than one instance visible at the same time. If I work on two pieces at the same time, it's extremely helpful and time saving to see both scores at the same time (provided you have more than two monitors). I normally used three large monitors and it's really a nightmare to be forced to use a single laptop screen and tabbed scores.

If I need more than one score at the same time, I therefore open an additional instance of Frescobaldi and place that view on the other monitor. This is necessary because you cannot "pull" the tab and place that view on about score (like Chrome).

I've not worked with MuseScore 3.x but only 4.0.x and have no experience with Mac so I cannot compare.

In reply to by tommy_strandbe…

It's the exact same issue in MuseScore 3 which is one reason why many find the separate windows to be superior, and why so many users have request it over the years. It's a minor difference in the grand scheme of things, but, as with Coke vs Pepsi, there will always be those preferring one over the other strongly enough that they will choose an otherwise inferior restaurant just because they serve the soft drink of their choice :-)

In reply to by Marc Sabatella

This misrepresents the issue, which is not so much separate windows, as different instances of the app running simultaneously.

Different windows under the umbrella of a single executable are fine and can serve as a good ordering principle within a complex app. That is, if the app has an intuitive way of switching between them, as for instance through a drop down box common to all windows. A main problem with the current implementation (apart from being very inefficient in terms of memory usage and a problem for global settings) is that switching between scores is very inconvenient, at least on Mac.

The real problem is not that different scores are in different windows, but that these windows are managed by different instances of the app. Which is not cosmetic, but fundamental.

In reply to by user2442

One person thinks most people just write lead sheets. Another thinks most people edit scores. I suspect that both are uses, but not really most. I don't think MuseScore has ever been a one software does everything program. I don't think that exists. People have their own ideas on how to "fix" MU4. Heaven knows there are plenty of things that I'm not sure I like about it. It's easy to say things about what we think the developers should have done. I don't think any of us can Fix MU4. Despite what we think we know. Those that might know ought to set about doing it. I don't edit scores or write lead sheets. I compose for orchestra. I have no use for MU3. I don't even have it on my new computer.

In reply to by user2442

Again, I see that you personally are concerned with that detail, but my point is that others seem more concerned with the loss of the tabs themselves. Different people have different preferences indeed. But again, there is really no point in continuing this thread. The issue is understood by the developers, and this thread is on a site the developers do not generally visit anyhow. There is nothing to be gained by further discussion here.

In reply to by user2442

As I have explained, so far no one has found a solution, but it's on the list of things to continue investigating. I can't tell you where that investigation will lead because no one knows - it's still ongoing.

Personally, I think Mac users should band together to complain to Apple about their poor design choice not to combine the icons or show document names for multiple instances. If Apple were to fix that, then it would become mostly moot as it is on Windows, Linux, and ChromeOS. A little inter-process communication to update preferences between instances and there would be pretty much no user-visible difference.

In reply to by Marc Sabatella

You are mistaken about Apple. Your comment shows that you do not understand the principles underlying macOS. Which many would argue are sounder and more consistent than those of Windows.

But let us leave that discussion for others - only please do not rant about things unless you have put an effort in really understanding why those choices were made.

More to the current point: if Apple would show document names when tabbing or on the dock, that would solve the immediate problem of finding the correct MuseScore instance, but it would not solve the fundamental problems caused by having multiple instances running for multiple scores.

Synchronizing settings is one problem. But not the most serious. Resource consumption is. On my Mac, a single instance of MuseScore consumes between 1 and 2 gigabytes of memory. If I am editing a score and want a brief look at another one, again that amount of memory is consumed. Many users will run out of memory very fast that way. Talk about user-visible difference!

There is really no reason I can see that forces to open a second instance of the app just to work on a second score. To me that is sloppy programming, probably by people not really knowing their way around macOS.

You speak about poor design choices from Apple, but what about this design decision by the MuseScore/MuseHub developers? Look at yourself before blaming others.

PS This is not to be viewed as a criticism of all the MuseScore volunteers who, over the years, have created a wonderful program. We are all in their debt.

In reply to by user2442

this has always been the issue, and I complained that people weren't listening a year ago (nor were they listening six months ago). It makes features of macOS work very weirdly or breaks them; I do my modern music in Musescore, Gregorian chant in LaTeX with TeXShop. I can have both tabs or separate windows, all in one instance, so only one TeXShop icon is in the dock, but I can cycle through the windows with the keyboard or use Mission Control to view them all. If I want Stage Manager (rare, because I'm constantly going to Finder or Safari, but in theory) it works.

Yes, yes, not every app has tabs, but so what? Taking away tabs and then having this was not the way forward.

In reply to by luntastonemason

It's not a question of people "not listening". As has been explained many times, the issue is that thus far no one has found a technical solution to this particular macOS restriction. Not from lack of trying, but simply due to the complexities of the situation. Yes, of course, other apps that don't have to manage gigabytes worth of sound libraries that need to be associated with each score separately can get away with solutions that aren't viable for MuseScore. But those solutions would lead to problems worse than multiple icons if MuseScore tried them. So, new solutions need to be found, and thus far, nothing the experts have tried has led to a solution. They're still trying, though.

As always, since MuseScore is open source, if any macOS programming experts out there have ideas they'd like to try out, they are most welcome to, and if they find a viable solution, no doubt it would be greatly appreciated by the MuseScore community!

In reply to by Marc Sabatella

It is, actually, that problem, and the condescension in your comment underscores it. I also would point out the many replies to me and to others where people kept yakking on about Windows or Linux, even after it became apparent that macOS expects something else.

As another user said, "To me these are the three most serious issues [Allow Multiple Tabs to be open in one instance of program, Allow user to Manually update sounds on Musehub (don't have it running in background), a visible save button] because they are not bugs they are by design." There's really no answer to his criticism, except by deflecting onto the technical challenge, and then you have "I don't know which platform the OP is using, but on Mac, opening another document opens another instance of MuseScore. I have not seen anything like that in many, many years of using a Mac…"

No answer!

No answer to the many, many comments saying how terrible it is with the way that the icons then close on a Mac.

"Other things that Word does well despite being multi-window: change your ribbon in any of the Word window (+/- customize your MuseScore palettes), all other Windows immediately have your new ribbon. Or change an option, it is applied to all opened windows at once as well."

No answer! Just that since Word, on Windows (because people keep talking about file explorers and not Finder) does one thing, well, it's OK if Musescore does this screwed-up thing too.

In reply to by luntastonemason

I'm sorry you are seeing my honest attempts to be helpful as somehow "condescension". Not sure how that mistake could have happened, but definitely not my intent. Anyhow, as explained, it's a hard problem to solve, so fart experts have failed to solve it, but hopefully someone else will be able to soon!

As for "no answer" given in some specific thread or other, volunteers such as myself do try to respond when we can, but it's tough to keep up with every single post in a forum this big. So, now that you know the relevant information, feel free to join the effort and help out yourself by providing this information when people are curious about why it hasn't been solved yet!

In reply to by Marc Sabatella

I want to highlight a point. The opening post in this thread—and most of the subsequent replies—are OS agnostic. But since the release of MuseScore 4.0 it seemes that many users on all platforms complained about the omission of "score tabs" regression. Yet Mark's reply ("... thus far no one has found a technical solution to this particular macOS restriction") implies that the issue is MacOS specific. Or did I read that wrong?

If indeed the tab-less interface is a MacOS-only regression then it never was an issue on Windows and Linux. But if initially it was a Windows/Linux issue too, has that regression been resolved?

In reply to by scorster

The changes affects all platforms. But in Windows and Linux, the new behavior is actually quite standard and used by tons of other applications and is well supported by the OS, actually making the use model simpler in most respects. So it’s just a personal preference some people have for the other behavior.

On macOS, though, the new behavior is not one that the operating system supports well at all - it produces a mess on the desktop as a result. So the result comes off as much worse than it should - nowhere near as good as in Windows or Linux, and indeed, something that could legitimately be called a “bug” and not just a personal preference.

In reply to by Marc Sabatella

Except that no, on Windows as well the muti-instance is buggy.
Buggy because to change a setting you have to close all instances of MuseScore except one, change it and then only reopen all instances.
If you change a setting with multi -instances opened it only takes effect in the opened one, and you only keep the setting changes done in the last instance that you close.

In reply to by Marc Sabatella

@Marc: The real bug is that the developers took a perfectly working program and, to introduce some new feature, warped it into something that is not working properly anymore on one of the platforms it was developed for. (And on another not very well either, see @frfancha).

And that all to protect some proprietary technology. In an open source program. Thank you very much.

In reply to by user2442

@user2442 no that wasn't without a good reason. That is well explained in the github issue.
Part of that reason is the limitation imposed by the Qt framework, if MuseScore wasn't depending of Qt it wouldn't be forced to split the windows following the processes.
I'm not saying I like this choice, nor that perhaps it should have been designed better, perhaps extending the process model of Qt or whatever the solution could be. Or at the very minimum a shared process should have been implemented for the palette customisation right away.
I'm just saying, contrary for example to the removal of the save button, there was a reason.

In reply to by frfancha

There are always reasons for every decision leading to change, including not implementing a dedicated save button in the new interface. Assuming and asserting that changes are made for no reason is a great way to start an entirely unproductive discussion. One can quibble about whether one agrees with the reasons, or whether the decision should be reconsidered based on other factors, is fair game, But it has to start form a place of understanding or the discussion cannot possibly go anywhere useful.

In reply to by frfancha

@frfancha, did you read in my post that I think the change was made for no reason? I don’t think I said so; in any case, that is not what I meant. Of course the change was made for a reason that the developers at the time found compelling.

What I say is that, whatever the reasoning, one should not cripple an existing well-functioning program just to add new functionality.

For my education, could you explain which features of MuseScore 4 are forcing the “multiple tabs” behavior? There are undeniably improvements over MS3 in MS4, but which of these are forcing the issue? What would I have to sacrifice (in principle of course) in MS4 to have my old tab behavior back?

Thanks for your insight!

In reply to by user2442

MuseScore 3 forced all open scores to use exactly the same sound libraries - they were loaded globally into the Synthesizer window. Back in the old days when sounbfonts were the only choice, this was kind of sort of barely acceptable, with really awkward workarounds to allow each score to still play with its own sounds. Now that Muse Sounds and VST instruments are in the picture, that model is just not viable anymore.

So bottom line: in order to support Muse Sounds and VST, it just wouldn't be practical or a good user experience to force all open scores to use the same sounds. Allowing each score to have its own instance of the sound engine is by far the most straightforward way to accomplish this, and so far, putting the score itself in a separate instance of MuseScore has been the only technical solution found that accomplishes this using the cross-platform frameworks MuseScore relies on.

Again, it's not like people aren't trying to figure out alternatives. But so far, all the promising-seeming ieas just haven't panned out.

In reply to by Marc Sabatella

@marc,
@frfancha,

thank you for reacting to my post and for providing explanation.

Can I ask some follow up questions? Not to be argumentative, but to help me understand. I know my way around software development, so don’t hesitate to get technical if the issue asks for it.

My goal with this is to determine if I might be able to help resolve the issue.

@Marc, you say “Now that Muse Sounds and VST instruments are in the picture, that model is just not viable anymore”. Again, not to argue, but what exactly is it that makes the model not viable anymore? An obvious approach would seem to create a separate sound back end for each score that needs one, and switch to it when that score is at the foreground (being worked on). Then no separate instances of the program would be needed, since the one instance has access to all the sound configurations. That scenario is probably too simple, but where does it go wrong?

@frfancha, not sure if we’re talking about the same problem. I have no issue with separate windows - actually, I like it. One window per document, multiple tabs per window for different views on the same score. Great. (Or a single window with multiple tabs for different views on one score at a time, plus a drop down menu to switch between scores if people prefer. Also fine.)
But this topic is called “multiple tabs”, which really is a misnomer. The Mac issue with MS4 is not multiple tabs, nor multiple windows, but that there are multiple instances of the app running, one per document. Whereas the Mac way is to have one instance running, managing multiple documents. MS3 followed that route. (Multiple instances bring all kinds of problems, as mentioned before in this topic.)
If we are agreed about the issue, my question is: why exactly is it that the use of Qt forces separate instances? After all, Qt is about providing the front end, and, with a clear separation between front end and back end, it seems to me that there need not be a problem. I might be mistaken, though, and if so, can you indicate where?

I appreciate any help you both can provide.

In reply to by user2442

By "not viable", I mean, it would be completely unacceptable to almost all users if all scores had to use the same sound libraries. There are few users who for whatever reason seem to prefer tabs to multiple windows as a purely personal preference. But virtually everyone would be adversely affected if loading a given sound into one score started affecting all open scores. Again, it was kind of sort of barely tolerable when the only sounds available were soundfonts, and you could use the awkward kludgy workarounds to still have independent sounds if you managed the synthesizer and mixer carefully enough. ut having to do that x100 once Muse Sounds and VST's are available would be absolutely unacceptable to anyone who ever listens to playback. That is why the MU3 approach is not an option.

And yes, for macOS specifically, that operating is extremely limited (by design, apparently) in its support for multiple instances. So this is recognized as a real problem indeed, and again, people have been searching for solutions for this. So far, though, nothing tried has panned out. If you have macOS systems programming expertise you'd like to contribute to the effort, you are very much welcome and encouraged to!

In reply to by Marc Sabatella

Thanks for replying, but that is not what I meant. I understand that every score needs its own sounds. Let me clarify my question.

I meant, for every score/window, to load a new sound back end (for Soundfonts, MuseSounds, whatever) and configure it to produce the sounds the user wants for that particular score - while keeping the other back ends, all configured for their own window/score, available.

With “sound back end” I mean that part of the program that is talking to the sound library.

Then, when the user switches to a particular window, the program will switch to the associated back end, so that the library will be properly instructed and the sounds will come out exactly as desired.

Such a setup would be a pretty standard way to handle the situation. My question was, and is: what in MS4, if anything, is preventing it? There must be a reason, and understanding that might point the way to a solution.

Do you still have an unanswered question? Please log in first to post your question.