Launching multiple instances?
I've noticed that when I open multiple scores in MS4, each one appears in an entire new instance of the program (rather than on separate tabs where they can be compared, copied, etc.). Can this possibly be by design?
Do you still have an unanswered question? Please log in first to post your question.
Comments
Yes, it is by design
As noted, yes, it's by design, for reasons that are detailed elsewhere (short answer: so that you can easily have different sounds for different scores, unlike MU3).
But to be clear: scores can be compared and copied across instances, more easily in fact than across tabs since you can view them simultaneously and use Alt+Tab to quickly switch back and forth between them.
In reply to As noted, yes, it's by… by Marc Sabatella
Marc > ...Scores can be compared and copied across instances, more easily in fact than across tabs since you can view them simultaneously.
You're right! For some reason, I assumed music couldn't be copied between separately running instances—they were separate, right? But of course MS knows how to interpret its own clipboard content, whether the copying occurs within the app or via the Windows clipboard (which may be, for all I know, one and the same).
To top it off, my 12-year-old Sibelius 6 hadn't even gotten to tabs yet. You either had to "tile" two scores side-by side, or use the "Window" menu to switch from one to the other. Two MS instances isn't bad at all—for, as you mentioned, it makes the system-wide Alt+Tab command available. Life is good!
In reply to Marc > ...Scores can be… by Andy Fielding
And Sibelius 7.5.1 doesn't use tabs either. Nor does Word, or Audacity.
In reply to And Sibelius 7.5.1 doesn't… by bobjp
Except Word shares your settings between instances, changing options or ribbon in one of them propagates the change in all of them.
In reply to Except Word shares your… by frfancha
I'm just saying that the lack of tabs is not a problem for me at all. But we're all used to different things. Like the one person who loads 150 scores and plays from them.
Another advantage of multiple instances: if one crashes, the others are still ok.
In reply to Another advantage of… by [DELETED] 1307581
That's right! In fact, till MS 4 becomes a bit more stable, I think I'll open each score I'm working on in three instances, just to be on the safe side—yet another benefit of not using tabs. 😄
This is objectively bad. If I open various scores via a terminal, and I end up with 100 instances of MuseScore (instead of 100 tabs) this is just bad.
There may exist good reasons for this design choice, I'm not saying to change the default, but there should at least be a commandline option that prevents another instance from opening, e.g. --same-instance or --tab.
The problem is not the default, the problem is not having options to change that.
In reply to This is objectively bad. If… by 255
Especially for MacOS, there has been a discussion about running "multiple instances of one app" versus running "multiple files within the same instance".
See:
https://github.com/musescore/MuseScore/issues/12647
In reply to This is objectively bad. If… by 255
• It's only subjectively bad.
• There are design reasons for the decision.
• Future development may overcome this limitation.
• Workaround: Don't open 100 scores; just open one or two.
In reply to • It's only subjectively bad… by yonah_ag
yonah_ag > Don't open 100 scores; just open one or two.
I take it you're not an arranger. 😄
In reply to yonah_ag: Don't open 100… by Andy Fielding
I arrange for solo guitar but ...
... having migrated to MS4 in recent months I have to agree that the lack of multiple tabs is counter productive, even for solo guitar where I may reference several scores at once. I used to stack tabs vertically or horizontally in MS3 and I do miss these options.
It feels so clumsy to have separate instances even in Microsoft Windows and I gather that it's even worse for MacOS users.
In reply to I arrange for solo guitar… by yonah_ag
We agree, then: Tabs would be great! Running multiple instances of MS seems much more complicated, if anything—not to mention, pretty 2000s. 🤷♂️
And doing it by design, so we can "have different sounds in different scores"? Really, guys? Not just assigning whatever sounds we need, wherever we need them? Maybe I'm missing something, but that one baffles me.
In reply to We agree, then: Tabs would… by Andy Fielding
If you're on macOS, then indeed, that platform does not support multiple instances well. On all other platforms it is simple. So, as explained many times, alternatives are being sought. Ideally, Apple would just fix their OS, but meanwhile, people with expertise in this aspect of software design are highly encourage to help on the effort to find workarounds to that OS limitation. On other systems - Windows, Linux, ChromeOS - multiple instances are not problematic at all, and it is 100% subjective as to which one might happen to prefer (if one has a preference at all).
As for "different sounds in different scores" and why that is important, this too has been explained multiple times, but for those who need a refresher:
Previous versions required all currently open scores to share the same set of loaded soundfonts. That means, if you want two open scores to use different soundfonts, you had two chocies - either load and unload soundfonts every time you changed tabs, or else have MuseScore load all soundfonts you plan to use every time the program starts. The first is obviously terrible; whatever possible advantage you might think you were gaining by using multiple tabs would be lost if you needed to re-load your sounds every time you switched tabs. So of course, virtually everyone wanting to use multiple sound libraries opted for the second option: load them all when the program starts up. This means, the memory required by the process is increased by the total of all soundfonts you use, and the time to startup is also proportional to the total size of all soundfonts loaded.
That model worked fine when all we had were soundfonts, whose sizes are typically measured in tens or occasionally hundreds of megabytes at most. Move forward from how things were in the early 2000's to how things are today, with VST instruments and Muse Sounds available. Now we're talking about potential tens of hundreds of gigabytes of sound libraries. Do you have that much available RAM? Probably not. Having to laod all possible sound libraries on startup was barely tolerable in 2000, but would be completely unacceptable today.
That's not all there is to it, but hopefully that gives some idea.
So again, anyone who has expertise in this aspect of systems-level software design is more than welcome to contribute to the effort to find alternate solutions to workaround the severe limitations maxOS places on software using instances. And if it happens to also provide a way to provide the option of tabs instead of / in addition to windows on other operating systems, so much the better.
But simply complaining about it over and over - and continuing to ignore the very real technical issues involved - is not helpful. Not even the tiniest slightest bit.
In reply to If you're on macOS, then… by Marc Sabatella
Even on Windows it's less than ideal as each instance of the program requires the UI framework and panels which take up screen space. The horizontal and vertical split screen options of MS3 were much friendlier to use. They even allowed the user to edit different parts of the same score across the split window — very handy.
Maybe a compromise could be implemented: allow multi tabs but require the user to configure a list of sound libraries to be shared in common across all scores opened across the multiple tabs.
In reply to Even on Windows it's less… by yonah_ag
One bug with these multiple instances: change preferences in one session, but close another session later: the change in preferences is lost
In reply to One bug with these multiple… by Jojo-Schmitz
Actually, not true for preferences - there is interprocess communication to dealw ith that. Changes in one window immediately propagate to the others. But palette customizations currently do not do this. It's technically possible, just no one has considered it important enough to volunteer to do yet. That's actually the only aspect of the current system that impacts me negatively. Still minor compared to the huge advantages of being able to take advantage of the OS-level window management features of Windows, Linux, and ChromeOS.
In reply to Actually, not ture for… by Marc Sabatella
Hmm, OK, so I misremembered. A tiny bit...
In reply to Even on Windows it's less… by yonah_ag
As I said, it's subjective, as there are tradeoffs. Being able to easily Alt+Tab back and forth is a huge win that to me dwarfs any other minor nuisance. But, split screen is not the same as tabs, so that's not really even relevant., In theory split screen views is possible even with multiple instances, and it would be possible to have tabs without split screen. If you want to talk abotu split screen views, that's another topic.
Anyhow, to me, the multiple windows are way better than tabs, but in the grand scheme of things it wouldn't be worth 10 minutes of my time to complain about if for whatever reason they solved the playback isses and found a way to do tabs and then made that the default.
ANyhow, again, if anyone has thre tehcnical skills to design alternatives that work, they are more than welcome to get involved in the development - MuseScore Studio remains open source (and always will).
In reply to As I said, it's subjective,… by Marc Sabatella
Split screen was just another example. And also another regression.
Anyhow, to me, multiple tabs are way better than multiple windows, and in the grand scheme of things you could continue to use multiple windows if the multiple tabs problem is solved. Then we could all have our preference.
In reply to If you're on macOS, then… by Marc Sabatella
Not to pointlessly perpetuate the "complaints", Marc, but:
Marc > That model worked fine when all we had were soundfonts, whose sizes are typically measured in tens or occasionally hundreds of megabytes at most. Move forward from how things were in the early 2000's to how things are today, with VST instruments and Muse Sounds available. Now we're talking about potential tens of hundreds of gigabytes of sound libraries. Do you have that much available RAM? Probably not. Having to [load] all possible sound libraries on startup was barely tolerable in 2000, but would be completely unacceptable today.
You'll notice that between my first and second replies here, my attitude about tabs had changed. Now I wish we had them.
If one's really using the RAM-overwhelming sounds you describe, and wants to keep scores open that use them, I don't see why it'd matter if the scores were on tabs in one window, where they were more easily accessible, or each in its own instance of MS. Whenever you switch to one of those other scores, the system must do whatever it has to do to make those sounds available.
If one regularly uses more sounds than they have RAM, the answer isn't to complain about it (speaking of complaints, LOL), but to add more RAM. I don't use massive sounds myself—but that's what the arrangers I know who do use them do. If you need an adjustable wrench, and you can buy one, you needn't keep using pliers like one.
So maybe I'm not getting something—but this line of thought seems unrelated to whether MS should have tabs. It's more about how much RAM one has, and how many gigantic sounds one expects to use with it. The rational approach is to either add more RAM, or use smaller sounds.
In reply to Not to pointlessly… by Andy Fielding
If you feel like volunteering your expert software engineering to design, implement, and maintain into perpetuity two different user interfaces - one that works well for the vast majority of people, the other than is optimized for use by those who prefer tabs and promsie to either never use MuseSounds or else only use computers with my than 32 GB or RAM, then I'm sure your contributions will be welcome.
I look forward to seeing your PR with your code changes to support this dual mode interface!
But meanwhile, programmers need to focus on providing the one interface that works best for the vast majority.
In reply to If you feel like… by Marc Sabatella
Marc, I appreciate the compliment, but I don't think one need be an "expert software engineer" to understand what things like windows, tabs, RAM and sound files are, do they?
While I'm sure I'd enjoy being part of the MS project, I already have a job (I often post things here related to it)—so my contributions must be limited to my yearly "Pro" subscription, and the suggestions and feedback I can offer here as someone who uses MuseScore professionally, and who's used every major notation app since the days of MS-DOS. (It's amazing I can even find my way back here, isn't it?) Thanks, though! 🎼😊👍
In reply to Marc, I appreciate the… by Andy Fielding
Yes, I know I'm replying to myself... Don't worry, I'm not senile—yet. 😄
I was still wondering about all this. Do MS's developers actually prefer running a separate instance of the whole program for each score? Or could there be more to it?
So I ran the issue by a popular LLM I often consult on other music-related matters (and which I can confidently say is a "software expert"). Here's what it had to say. Its explanation make sense to me—what do you think?
> I think this disconnect is occurring because the moderator may be thinking from a viewpoint of the past, but the software itself and its users are very much in the present. It seems like their argument, while technically sound from a certain perspective, is not accounting for the reality of how the program is being used today.
> The key issue here is likely legacy code. When a program has been in development for a long time, the core architecture is built around the limitations and assumptions of its time. To change a fundamental behavior—like how it manages multiple scores and their associated sound libraries—often requires a massive and expensive refactoring of the code.
> What you're seeing may be the result of a compromise. The MuseScore project started off as a free notation program, and now they're adding paid, professional-level features on top of that older foundation. It's a pragmatic approach to development: They're adding the functionality that users want (massive sound libraries) without having to do the monumental work of redesigning the core of the program to support a modern, tabbed interface. They're probably thinking that the performance hit of having multiple instances is an acceptable trade-off for not having to rebuild the entire application from scratch.
In reply to Yes, I know I'm replying to… by Andy Fielding
Sounds like a typically plausible-sounding-but-compeltely-incorrect AI guess indeed.
As for separate instances - I don't know that anyone actually prefers that over separate windows in the same instance. In theory there would be no user-visible difference between the two, and there isn't on msot modern operating systems - only macOS handles multiple instances in such a poor way that users are acutely aware fo the difference. But to be sure, yes indeed, many people - developers and non-developers alike - prefer using multiple windows over having everything crammed into a single window.
In reply to Yes, I know I'm replying to… by Andy Fielding
> "The key issue here is likely legacy code"
I am under the impression that the code was re-written from the ground up for version 4. No--or, at least, very little--legacy code involved.
I am not on the development team so perhaps my understanding is incorrect?
In reply to > "The key issue here is… by TheHutch
Well, it's not the case that all the code was replaced - really, probably 90%+ or more is the same (or only modified a "normal" amount to fix bugs & add new features) between MU3 and MU4. But two main things were re-written: the main window UI, and the playback engine. And these are precisely the things that are involved here. The "legacy code" supported tabs just fine - it just had those other deal-breakers problem (somewhat tolerable in a world where only soundfonts are supported, but unacceptable with MuseSounds and VST). So it's the fact that don't rely opn legacy code here that allows us to take full advantage of the multiple instances supported so well by almost every modern operating system in the world, with the unfortunate exception of macOS. But workarounds continue to be explored. If it were easy, it would have been solved by now. If someone reading this has insights and the time to volunteer, you can make a difference!
In reply to Marc, I appreciate the… by Andy Fielding
You don't need to be an expert software engineer to know the basic dictionary definition of those terms, no. But you have to be extremely knowledgeable to actually be able to solve the problems I explained. Or maybe you think it's soemthing that doesn't require much expertise. In which case, it should be an easy matter to find a volunteer willing to do it. Just keep in mind, a whole team of highly experienced professionals who are intimately familiar with the issues involved has not yet found a way.
In reply to You don't need to be an… by Marc Sabatella
How about a setting where the user can define a set of sound libraries to pre-load before the score, then restrict multi-tabs to use this set? If a required sound is not available in the set then the system could 'fallback' to the first sound of the first library referenced.
In reply to How about a setting where… by yonah_ag
Designing, implementing, documenting, supporting, and maintaining two completely separate facilities - one of which that would only be useful for a small subset of users - would be a pretty colossal drain on resources that could be better spent fixing bugs, implementing features, etc. Much better to simply find a solution to the unfortunate macOS limitation on multiple instances.
In reply to Designing, implementing,… by Marc Sabatella
It's really annoying on Windows too. Multi-tab is much more elegant.
MS3 has a synthesiser where the sound libraries for pre-loading can be configured. Fallback happens for scores which reference sounds outside of the loaded ones. So, it's a solution which the earlier development had already implemented.
In reply to It's really annoying on… by yonah_ag
There is no objective sense in which tabs are better than windows on Windows (or Linux, or ChromeOS) - it's completely personal preference. It's only macOS where there are objective differences that affect everyone regardless of personal preference.
The facility you mention would in no way have any bearing whatsoever on the much bigger problem I have been describing.
In reply to There is no objective sense… by Marc Sabatella
Objective:
1) Tabs lose less screen to the UI frame and panels.
2) Multiple instances use more memory.
The facility that I mention seems highly analogous to the bigger problem. Sure, VST and MuseSounds libraries are way bigger than SF2 soundfonts but it's just a bigger 'credit limit'.
In reply to Objective: 1) Tabs lose less… by yonah_ag
I don't see how tabs change anything about the size of the other panels. In fact tabs take more screen real estate than multiple windows - at least when comapring MU3 to MU4 - because MU3 requires two tab bars (one to select scores, another to select parts within them) whereas MU4 needs only one.
Also, tabs limit you to viewing one score at a time while multiple windows allow you to view multiple scores at once. Maybe you are confusing the tab/window distinction with the entirely separate matter of a split screen view - the specific feature MU3 had to allow multiple scores to be visible at once despite the tabbed interface? That is, again, a wholly separate matter, and sure, a split screen view or other UI for showing scores side by side without duplicating the toolbars and panels would be useful to see return. In principle, there is no reason that could not be done within the current framework, though.
Also, it's not true that multiple instance require more memory in any practical sense. By definition, multiple instances mean the application code itself is shared between them, and any modern operating (like iterally anything going back to the 1970's) knows how to handle that. Operating systems are also quite efficient at managing the swapping of the data between processes - it's normally more efficient than managing the swapping of individual pages within processes when memory is tight.
In reply to I don't see how tabs change… by Marc Sabatella
By having 2 instances of MuseScore open don't you have 2 x UIs on your monitor if you want to see the scores together? The UI takes quite a bit of space, so 2 x UI takes even more.
Multiple instances means separate non-shared runtime memory space allocation and therefore higher memory usage. For example, with Microsoft Excel you can choose to open a separate instance, (alt-launching), which takes more memory but mitigates crashing, e.g. with VBA.
In reply to By having 2 instances of… by yonah_ag
Again, tabs by themselves do not make it possible to view two scores at once - quite the opposite in fact. The only reason it was possible to view two scores at once in MU3 had nothing to do with tabs vs multiple instances - it's because it implemented a completely separate "scores side by side" feature. As I explained above, such a feature does not depend on tabs at all and could be implemented in MU4 - it just hasn't been yet.
So what you are describing is not an advantage to tabs themselves. It's just an observation about a separate unrelated feature MU3 also had. Without that separate unrelated feature, tabs would have prevented you from seeing two documents side by side, and you'd be here observing that multiple windows is objectively better because it does allow that.
So anyhow, yes, a side by side feature would be nice to have in MU4, no doubt. But that has no bearing at all on the tab vs instances issue in general.
In reply to Again, tabs by themselves do… by Marc Sabatella
The logical extension to multi-tabs is to show them split screen, saving on UI space. The starting point is multiple scores managed by a single instance of Musescore.
Multi program instances still mean more memory is used.
It would help in MS4 if some of the UI panels could be resized as much as MS3 allowed. The palettes panel is particularly averse to resizing.
In reply to The logical extension to… by yonah_ag
I don't know how I can possibly be clearer:
Split screen is a separate feature, not related to whether tabs or windows are used otherwise. if you miss split screen, fine, just say so, and stop confusing the issue by talking about tabs.
As I also explained, multiple program instances do not use more memory. i take it you didn't understand my explanation, which is understandable if you don't have a masters' degree in computer science with a focus in operating system design as I do. And that's fine. But please don't try to tell me how computers work.
And yes, as yet another completely and utterly unrelated issue, it would be nice if the UI in MU4 were more resizable. None of this has anything whatsoever to do with tabs. though.
In reply to I don't know how I can… by Marc Sabatella
Split screen is single instance, just like tabs is
In reply to Split screen is single… by Jojo-Schmitz
The specific implementation used in MU3 was single instance, obviously. But that doesn't mean it has to be that way. It would be perfectly possible to implement a split screen view in an application that otherwise uses multiple instances. And again, tabs themselves don't implement split screen - it's a separate feature. And I suspect you remember when MuseScore had tabs but did not have split screen.
In reply to The specific implementation… by Marc Sabatella
Sorry, but this is nonsense. It is not possible otherwise. Split screen has just one menu bar, just one palette, just one properties tab etc. so it is a single instance.
In reply to Sorry, but this is nonsense… by Jojo-Schmitz
It is not nonsense at all I can easily see how a system could be designed and implemented that used to instances communicating via the one toolbar. Or one in which changing focus also changed the location of the toolbar. Or that used s single instance just in this one limited way (subject to the same playback limitations as MU3), while still using multiple instances in the general case. It's quite solvable
In reply to It is not nonsense at all I… by Marc Sabatella
C'mon, if it is that easy, why has it been done years ago?
In reply to C'mon, if it is that easy,… by Jojo-Schmitz
Same reason lots of other useful things haven't been done while others have - limited resources means things need to be prioritized.
BTW, note that I didn't say it was easy, and I wouldn't have said it was easy to do for the old tabbed interface either. It was part of one of the most ambitious GSoC projects that I can recall, in fact, completed by one of the most brilliant programmers to have worked on MuseScore.
In reply to Same reason lots of other… by Marc Sabatella
I can easily see ...
It might be possible, but for sure it is not easy at all
The tabbed interface existed in Mu1.0 (and on the 0.9x versions before too IIRC) already, long before MuseScore's 1st GSoC participation as far as I can tell
In reply to Split screen is single… by Jojo-Schmitz
As an experiment, I opened Task Manager. Then MU4. Memory usage was around 25%. I started opening MU4 orchestra scores until I had ten open. Memory usage was 95%. OS Windows 11.
Then I tried the same in MU3. Only the score open in the score window was counted in Task Manager. Not all of them together.
I'm just passing this along. I have no interest in MU3, or having multiple scores open at once. Probably doesn't mean anything because I don't have a computer science degree.
In reply to As an experiment, I opened… by bobjp
Task manager measures total process sizes. It does not account for the factors I described. At least, not in that way.
In reply to Task manager measures total… by Marc Sabatella
Ten instances open in each Version of MuseScore.
Multiple instances in MU4 require memory for each one. The same number in MU3 only need memory for the one score open in the score window.
This is one point that yonah_ag was trying to make.
In reply to Ten instances open in each… by bobjp
Well, a single instance with one score needs less memory thsat a single instance with 10 scores.
But indeed most probably less than 10 instances with a single score, even if those also share some common memory.
I don't see any use of shared memories (and semaphores) in MuseScore code BTW. And having used them myself in code in a prevoius life, I'd recognize that...
In reply to Well, a single instance with… by Jojo-Schmitz
The shared memory would be at the OS level - the code for the application itself as well as for any dynamically linked libraries that are part of the process' memory space can be shared between all processes using that code. This code sharing and reduction in memory is one of big reasons shared libraries took off so big despite the complications involved (disk space savings were of course another reason).
In reply to The shared memory would be… by Marc Sabatella
If 2 instances were sharing the memory of a dll, both would crash if there's a problem in that dll, or even the OS would panic (BSOD on Windows). They don't, because they have their own address space.
Well, they can share parts of a dll, some read-only stuff, but that's about it. But that certainly is on OS level too, just like share memory would be
In reply to If 2 instances were sharing… by Jojo-Schmitz
? All of the code for shared libraries is shared. The only code that is not read-only is "self-modifying code", and that's not a thing here. FWIW, I do have some actual experience here aside from merely having a degree in this stuff - I implemented the shared library scheme for HP-UX back in the day.
In reply to Ten instances open in each… by bobjp
Thank you bobjp, that was precisely my point.
In reply to Ten instances open in each… by bobjp
This is just not true; it's not how operating systems work. The program code itself is shared between all instances. It's mostly just the score data that is different for each instance, It's the same amount of score data either way, just a question of whether it is spread out over multiple instances or all piled into the same instance. And the former is much more efficient for the OS to manage: it can easily swap in all pages for the process when you switch scores. Whereas when all data for all scores is in one process, the OS can't really track which data goes with which score so there will be more guesswork in deciding which pages to swap in when switching scores.
In reply to This is just not true; it's… by Marc Sabatella
Thanks to all of you for your thoughts on this. Clearly there's much more to it than most of us realize.
I'm afraid I haven't any more time for this topic, but I appreciate your time. Cheers!
In reply to This is just not true; it's… by Marc Sabatella
As per Task-Manager
1 Mu3.6.2, 1 score: 288,6MB RAM
1 Mu36.2, 10 scores: 446,6 MB RAM (so less than twice the size)
1 Mu45.2, 1 score: 522.7 MB RAM (already more than double of Mu3)
10 Mu45.2, 1 score: 5283.3 MB (so almost exctly 10 times a single instance)
Exact same scores (so 3.6 ones for Mu4 too), rather small ones too (11 to 44 kB each), Mu4 configured to not use Muse Sound (which most probably would result in an even larger footprint).
In reply to As per Task-Manager 1 Mu3, 1… by Jojo-Schmitz
Exactly!
For each separate instance, the OS loads a copy of the program, (.exe, .dll etc), from disk into RAM. (The C++ runtime and Qt libraries may also be loaded for each instance but I'm not sure).
The small footprint of MS3, (even with 10 scores loaded), means that OS memory paging is likely to be irrelevant as the configuration is more likely to not need paging out of RAM. But with MS4 using so much more RAM to handle 10 scores, paging is much more likely.
In reply to Exactly! For each separate… by yonah_ag
paging is much more likely
and very annoying when used to copy/paste between them
Since the code for multi tab has already been developed for MS3, would it be a practical solution to port this code to MS4 but restrict multi-tab playback to Basic Sounds?
In reply to Since the code for multi tab… by yonah_ag
Multi-tab support is in MuseScore basically ever since, at least as long as I remember, and I started using MuseScore some 15 1/2 years ago (must have been version 0.9.5 back then)
In reply to Multi-tab support is in… by Jojo-Schmitz
So would a 'basic sounds only' port be practical or wouldn't this work with MS4's sound engine? There are definitely times when multi-tab editing is more important than playback quality.
In reply to So would a 'basic sounds… by yonah_ag
And to go along with JoJo.
This is with the same score.
MU4 with Muse sounds. 716 MB
MU4 with Basic sounds. 768 MB
MU3. 250 MB
In reply to And to go along with JoJo… by bobjp
Surprising (to me) that MuseSound need less memory
In reply to Surprising that MuseSound… by Jojo-Schmitz
And it fluctuated the longer it was open, even though I didn't actually play the score.