Our Progress on MuseScore 4 - Update 1

• 12. Apr 2021 - 13:56

[Edited for clarity: 14, June, 2021]

Hi everyone,

I wanted to give a general update about the remaining work left on MuseScore 4. We've recreated most of the new interface and functionality now and have ported over most of the MuseScore 3 functionality too. Now we feel it is possible to begin mapping out a draft release schedule, although there are still some large chunks of work that are hard to estimate so this timeline may change (hopefully by getting shorter!). In addition, I want to describe what aspects of the application we are planning on delaying until a future release (4.1, 4.2, etc.).

Playback

The single largest piece of remaining work relates to playback. The 'primary' Fluid synthesiser will remain the default, as is the case with MuseScore 3 but we will be removing the the 'secondary' Zerberus sampler/synthesiser and replacing it with VST support (Zerberus is incompatible with the GPL3 license, which we needed to switch to in order to support VST3). We are also developing an optional sound library that will not be packaged with MuseScore, which can be downloaded and activated (for free) once the application has been installed. We will create a separate detailed post about this shortly.

Another consequence of moving to GPL3 is that the old reverb and limiter effects (Zita & SC4) will need to be replaced with new VST effects instead. For now, when installing the new MuseScore library, we will also download and install two of our own VST effects to make up for this. Since we are only beginning on our VST journey, there will be many opportunities to integrate compatible VST and VSTi plugins in later releases.

We will be removing the 'Synthesiser' panel entirely from MuseScore and building some of the functions it served (ordering sounds and library priorities) into our new Mixer. For 'master' FX, we will be creating new auxiliary channels in the mixer, where the reverb FX will be situated. We will be saving user preferences relating to playback (VST settings, Aux channel settings, preferred libraries, etc.) in our project files and will be removing the concept of 'Save to Score' and 'Load from Score'. Instead, we want to develop a system for efficiently switching between projects that have different playback settings.

Stabilisation

We are aware that it can be difficult to determine which parts of MS4 are 'finished' (but still have optimisation bugs) and which parts are just incomplete. We are going to start marking these different strands of work clearly to help the community understand where they can feel free to optimise and improve functionality and where they can expect more changes to appear. The terms we are thinking of using are:

Not started

Incomplete (the designs have not been fully implemented)

Feature Complete (requires optimisation)

Release Ready (no optimisation required)

To give two examples (at the time of writing): Our new 'Note Input Bar' is Feature Complete: the designs have been full implemented but there are a few bugs. For example, when redocking the bar, the ordering of the buttons can become mixed up under certain circumstances. Community members can feel free to optimise this part of the app without worrying about new changes occurring which might cause conflicts and headaches. We constantly review bugs and publish them on our GitHub Projects page.

The 'Inspector' however is Incomplete: there are some parts where the designs have not yet been fully implemented and there is still some significant clean up work to do. In this case, I'll be publishing a new specification highlighting what remaining work needs to be done. In all cases: if community members want to take part in helping to complete work marked as Incomplete, Peter Jonas (our community manager) and I can work closely with you to hash out the details and make sure no work is lost.

Peter will shortly be publishing a general list that outlines the status of each chunk of work shortly. Peter also holds regular live build reviews on our Discord server, where this can be discusses in person.

Timeline

Below is our draft plan for releasing MuseScore 4. Note that marketing and automatic updates will not be switched on until after we are satisfied that the application has no remaining large issues.

(See the link below for a higher resolution version)
2021_TimeLine_Community_Version_v01.png

Delayed features

As announced last year, we decided to delay the sequencer view until a future release. This was a decision taken to enable us to work on a new playback library instead. Regarding the features from MuseScore 3, the main component we are also considering delaying is the piano roll - simply because it is gargantuan in size and because we also want to completely redesign and reimplement it. This is particularly painful because the addition of VST support will make the velocity controls infinitely more desirable and useful. However, we have estimated that porting over the existing piano roll (and incorporating into the new codebase) will delay the MuseScore 4.0 release by up to two months, which we feel is a step too far for a control we ultimately want to replace. This is not to dismiss the wonderful work done by Mark McCay (and others) on the MuseScore 3 piano roll. It is simply an awkward timeline issue.

As a backup plan, we are going to create a very simplistic design for a new piano roll, which will only contain the feature that allows users to edit velocity and expression settings. We are going to open up this design in case any community members wish to build it. We have also added this as a Google Summer of Code project, although it is unlikely that the outcome will be a feature that will be ready for MuseScore 4.0 due to the limited number of hours that GSoC students have to work with.

In the instance where there is no piano roll in MuseScore 4.0, users will need to edit velocity settings using the inspector, as in MuseScore 3. Don't worry though. The piano roll is a vitally important feature, which we are going to prioritise once MuseScore 4.0 is released.

After the release

The best thing about MuseScore 4.0 is that once we've built it (with its new architecture, playback engine and UI), we'll never have to build anything so massive ever again. We then intend to move to a steady release cadence, so we can gradually build up feature improvements in a more manageable and transparent way.

Anhang Größe
2021_TimeLine_Community_Version_v01.png 56.96 KB

Comments

• 23. Apr 2021 - 16:48

It's still early to say much about specifics on any feature, really. But one thing that was very recently implemented is an easier way to navigate between toolbars and windows within the interface, instead of a long tab journey from the score then through all the fields of the Inspector then through the toolbars then through the palette etc. Also, there is a basic Braille export facility that is implemented.

In addition, it is hoped that by MuseScore 4 we will have in place what we would need to finally support VoiceOver (and presumably Narrator as well, although hardly anyone seems to actually request that). But that's still easier said than done. And there is a possibility there will be support for additional color scheme options (eg, light-on-dark scores, for those on systems that don't support this directly already).

Are there specific things you are interesting in?

Antworten

• 23. Apr 2021 - 19:25

Thank you for your attention.
Reading the number of measures added manually, which is not accessible in the main palette window. (NVda does not read when added later.) Color schemes and magnifier support for low vision. Whatever can be done in the name of accessibility will make blind musicians like me happy. Voice support for Turkish and Arabic music will also make us happy. Thank you again.

Antworten

• 24. Apr 2021 - 01:19

Can you explain what you mean about reading the number of measures added manually? How are you adding measures? With the Add / Measures menu? Are you saying your screen reader does not read the number you enter into the dialogs boxes when using the options for multiple measures? The palette adds only a single measure, so there is nothing to read. Also, which screen reader? For me, Orca reads the contents of the dialog just fine, but I recall some screen readers have issues with spin boxes. Actually, probably best to start a new thread with any issues or specific requests, but for now, this is something we'd like to know.

Antworten

• 24. Apr 2021 - 10:39

Hello there,
1. I open the Master palette window with Shift + F9.
2. I choose the Time Signatures option from the tree view.
3. With the Tab key, I go to the "Create Time signature" field and type 5.
4. I write 8 in the second writing area.
5. I add the 5/8 measure number by pressing the Add button.
NVDA is silent when it comes to 5/8 on the list. But when I look at a sender they say there is a 5/8 measure number there.

Antworten

• 14. Apr 2021 - 18:40

Thanks. While most engraving-issues can be manually tweaked right relatively easily, getting horizontal spacing right is especially difficult and time consuming. Therefore I'm keeping my fingers crossed to see horizontal spacing improvements happen soon after 4.0 then.

Antworten

• 15. Apr 2021 - 04:38

I hope that Noteperformer will be supported eventually so I can purchase it. But this project looks great; I can't wait to see the new MuseScore 4!

Question: will MuseScore 4 have fixed the playback issues regarding section breaks and their behavior with repeats and jumps?

Antworten

• 15. Apr 2021 - 05:34

I have coding experience, and am on GitHub, even though my user experience is nil, and I would like to contribute to MuseScore. I had the idea that I could fix it, as I read in its big tracker forum why it doesn't work and what could be done to fix it. I am familiar with Python, HTML, and CSS, but not others. Is MuseScore written in Python? If not, I still might be able to figure out what do do, but at any rate I will be reading the Developers' Handbook. It's probably a lost cause on my part.

If the Section Break adds a pause at the end of a measure, perhaps that pause could be inserted at the beginning of the section, before its first measure, so it is played when the section is encountered, but not before.

Antworten

• 15. Apr 2021 - 19:00

"My dad used C++"

LOL, it's C++ not Fortran...

It's a fair bet most applications you use are written in C++.
Python is a fine language, but it's an interpreted language. Meaning it's run by the python application at run time and is inherently slower than a language that is compiled to machine language before hand (i.e. C or C++). Hence why major applications aren't written in it.

Antworten

• 15. Apr 2021 - 20:00

Depends what you mean by "similar". It is more like Java than Javascript. It is a block-structured language like Java, Javascript, Python, C, and Algol, but not Fortran or Lisp. But it is compiled, not interpreted, which means has a profound effect on what operations are permitted at runtime, which makes it more like Java, Fortran, Algol, and the like than Python or Javascript. Find some websites and learn about it, although the C++ used in MS is quite sophisticated, but you're really sharp :) ...

Antworten

• 15. Apr 2021 - 21:11

In Python or Javascript, you can add any property to any object at any time. In a compiled language, this is impossible. In Python or Javascript, you can pass any object at all to a function, and examine it to see what kind of object it is. In a compiled language, variables can only hold one type (as specified) of object, and only expressions and (contents or address) of variables of that type can be passed to functions expecting exactly that. C++ has type hierarchies and polymorphism, but you cannot pass a string to a function expecting an integer, etc. In python or javascript, lose the last pointer to an object, and it's garbage collected and gone. In a compiled language, lose the last pointer to an object and you have a memory leak (although there are storage management disciplines to minimize the chance of this). These are some of the important differences.

Antworten

• 15. Apr 2021 - 21:17

In python or javascript, any function can call any function at all without pre-arrangement. In a compiled language, you must declare the 'prototype' of any function you intend to use in a given module, including not just its name, but the value-types it expects and returns. This is often done by including "header files" full of such declarations. The compiler must know this to compile your program and generate linkage, so that that when the compiled program is loaded, these links can be connected to the right functions in other modules. Variables, too, must be declared, saying what type of value they hold. In Python or Javascript or other interpreted languages, this is not necessary, because objects are "typed" at runtime, and any variable can "hold" (or "point to" -- where it gets interesting) any value of any type. Not so in compiled languages; that's why they're fast.

Antworten

• 15. Apr 2021 - 22:19

That's fascinating; I never knew that. Everything I coded was JavaScript, HTML, CSS, and Scratch, where variables can be assigned any value. The only type errors I ran into were trying to perform operations on two variables of different types.

Yes, holding and pointing ("is" vs. "==" operators) in Python is a very interesting subject that I only recently came to understand.

Do you code Python and JavaScript as well as C++?

Antworten

• 15. Apr 2021 - 22:28

I've coded in about 30 languages, including many assembler and machine languages, 2 languages of my own construction, and all the major languages of the last 50 years. Lisp is my favorite, and today I use mainly Python, although I still have a major subsystem in modern C++. I wrote your plugins in Javascript, and all the
MS->Virtual Pipe Organ stuff (which I use with Hauptwerk) in Python. See my Github presence.

Antworten

• 15. Apr 2021 - 22:40

As I said, I've worked in Machine Language on many machines dating from the 1950s to the 1980s. The Raspberry Pi uses an x86-family processor, and the machine language for the x86 family is extremely complex because of optimizations in its design to keep the number of bytes it occupies to a minimum. The Mac I'm on now is really the first computer I've owned or worked on that I cannot access or program at the machine-language level. In the past, programs often failed at the machine level, so knowledge of hardware instructions was necessary. But with powerful modern IDE's (integrated development environments), this is no longer so (and yes, something is lost with beginners not knowing these things).

Antworten

• 16. Apr 2021 - 00:05

Yes, to both questions (it is an IDE), but in an interpreted language you need one a lot less. I debug Python programs, if needed , with the ancient "stick in a 'print' statement" technique; in a compiled language, that is harder/slower. Indeed, knowing how sequential processors (generically) operate is important to writing good code, although knowing specific binary op codes and instruction formats of a specific architecture is no longer important because of IDE's (unless you are actually writing compilers or operating systems).

Antworten

• 16. Apr 2021 - 12:08

Languages and compilers and interpreters for them are certainly being invented and developed. Google and Apple and Microsoft have all innovated new languages in recent years. "Operating system" is something completely different from "industrial device control program". Windows, macOS, and Linux are examples of operating systems under constant development and enhancement, although it would be near-impossible for a new operating system for personal computers to arise, because of the proliferation of applications requiring the interfaces of those. Interactive users and their applications are not at all like industrial pumps.

Antworten

• 22. Apr 2021 - 11:55

I worked (with others) on the development of two large operating systems, Multics and Symbolics Genera (Lisp Machines), the former historically significant. At no point did I "develop my own OS", although I certainly (at various times) developed single-user application control programs that could in theory could be called "dedicated OS's".

Antworten

• 20. Mai 2021 - 13:51

Languages aren't so bad if you use a compiler generator. Secify the language syntax, then assign the actions to be performed or encoded.

Ideally compilers or interpreter systems should be layered, so that they don't target just one hardware system, but can be mapped to different machines.

It's also not a bad idea (actually a very good method, IMO) for design. Design a set of fairly low level primitives for a system, and then write code to generate those. For example, for MS one could develop a modest bunch of primitives - such as write stave, put note on stave etc., then generate a system to perform those. With a decent set of primitive functions it's then possible to make changes both above and below that level. Changes above that level would be used to modify - maybe improve - the user interface, while changes below would deal with system and hardware level features, and possibly also changes could be made to get performane enhancements.

By having a set of layered constructs one can also construct hybrid systems, which mix compiling and interpreting - for example to obtain just in time compiling systems - systems which to all intents and purposes are as fast as compile language systems, but are very quick to compile.

Antworten

• 16. Mai 2021 - 11:04

Count your blessings.

PHP was originally developed, with all the best intentions, as a web programming language "for the kids". The first implementation was a cgi-bin Perl script! Although it's taken on all the trappings of a major programming language with a solid OOP class system a la Java, a massive ecosystem and JIT compilation, it still shows its origins with a massively inconsistent core library. To paraphrase the MS-DOS quote: "PHP is like a skunk that got run over by a locomotive; there's not much of the original left, but you can still smell it".

Ruby doesn't offer any real advantages over Python and is much more niche, clinging on in odd places like Rails and Puppet.

I have to deal with both and dislike PHP more than almost any other language. Ruby is OK, but not really worth the effort.

Interesting that you're in to language design. It's one of my favourite topics.

Antworten

• 19. Apr 2021 - 13:54

Hey! Be careful - I started in Fortran, coded in C before there was a ++; and have coded assembly for what was, in it's day, an amazing device - the Z80! And yet, I'm still alive and kicking! And even doing a bit of coding still. I even became an OO junkie at one point - can you say 'Smalltalk?'

Antworten

• 19. Apr 2021 - 14:14

I already did (say "Smalltalk"). I started in Intercom 1000 on the Bendix G-15, and have programmed in assembler from massive mainframes to microprocessors. There are many surviving career professional programmers from my generation. There will still be a need for people who can see eye-to-eye with a processor after there are no more librarians, transportation drivers, offices, or teachers.

Antworten

• 19. Apr 2021 - 14:39

@rocchio

Fortran was the first language I had to learn professionally. Spent a year on Fortran 4 and then we migrated to 77. It was well suited to the technical nature of the job and was a nice language to program in.

Z80 assembler was great fun on the ZX Spectrum until your code crashed and you realised that you hadn't saved it to tape - which was the only data storage format for the Spectrum - so you lost your code and then had to restart by loading the Assembly Language Editor back from tape into RAM followed by the latest save of your code.

Antworten

• 19. Apr 2021 - 20:47

I did love the Z80. For you, punch tape; for me, it was decks of Fortran punch cards spilled onto the floor of the Univ of Colorado computing center at 2am with the assignment due in the morning. Tho I suppose the thermos of daiquiris we smuggled in for the night didn't help any. And for any young-ns' listening in; for the record I'd much prefer to be called a 'dinosaur' (as in T-Rex) than 'gramps' (as in old geezer). Anyway - good to see that I'm not the only long-timer hanging out here.

Antworten

• 22. Apr 2021 - 05:39

Those old stories; I like hearing them. Punch cards are days long gone, but still entertaining to hear about; such as the story that the waiting involved was not punching the cards, but waiting one's turn to do so! I had no idea code used to be saved to tapes — so that's how they did it before disks. Fascinating; thanks for sharing. Sometimes I think I was born a century too late.

P.S. Was the T-Rex or Dinosaur an actual computer model, or just a nickname given to old stuff?

Antworten

• 17. Apr 2021 - 15:59

No. C++ is not outdated at all. While it can be rather obtuse, it still provides the finest control over what the machine/OS is doing. Interpreted languages like Python don't even come close in terms of efficiency. IMHO it's a great shame recent programmers can get their qualifications without understanding C/C++. It can be a steep learning curve, but the hard work pays off, and translates well in trying to make 'higher level' interpreted languages as efficient as possible. In my experience, you can spot a programmer without C/C++ skills a mile away: you don't have to use it for the task at hand, but it sure helps as a basis for understanding what's going on in higher level languages.

Antworten

• 17. Apr 2021 - 17:38

It may not be that useful on a basic programming course but I would hope that it is still part of university undergraduate degrees. It is certainly the most fundamental type of programming and still has relevance, e.g. PLC programming of older manufacturing machines.

I think that Clive Sinclair, (pioneer of cheap home computers back in the 1980's, based on the Z80A processor), cracked a clever joke regarding the name of his 1-person electric vehicle. It was called the Sinclair C5 and Z80 programmers knew that the hex instruction "C5" meant "Push BC". Sinclair seemed to be indicating that his vehicle was really a glorified Push BiCycle!

Antworten

• 22. Apr 2021 - 19:06

So whilst touting his "electric vehicle" he was telling us, in code, that it was really just a glorified push bike. It was ahead of its time and could probably be very useful these days. "Push BC" sounds and looks like "Push BiCycle" or "Push Bike".

2004.jpg

"Push BC" is indeed an assembler instruction to save the contents of the BC register to the stack and its machine code is C5 in hexadecimal, 11000101 in binary.

Antworten

• 25. Mai 2021 - 04:10

Not exactly… the assembly language of the 8080 differs vastly, it’s chiefly an 8-bit CPU, whereas x86 started with the 16-bit 8086 (and its 8-bit-data-bus-so-we-can-reuse-existing-mainboard-designs variant, the 8088, a year later); the current 32-bit and 64-bit instructions are more-or-less logical extensions of the 16-bit instruction set of the 8086 (including the binary opcode construction, such as the mod reg r/m bits).

Compare https://en.wikipedia.org/wiki/Intel_8080#Example_code with…

// entry registers:
// CX - number of bytes to copy
// DS:SI - address of source data block
// ES:DI - address of destination data block
memcpy:
cld
rep movsb
ret

OK, that’s cheating. Here it is using the same construct:

memcpy:
or cx,cx
jnz Lloop
ret
Lloop:
mov al,[si]
inc si
mov es:[di],al
inc di
dec cx
jnz Lloop
ret

Antworten

• 22. Apr 2021 - 16:42

Even better, they could learn a functional language, like Haskell - though I'm not sure I like the way that some functional languages went in recent years. I have not been convinced that monads are the way to go, though some of my friends like that.

Re speed and efficiency - just in time compiling is pretty good, and can achieve most of the benefits of machine code, while having greater flexibility - and makes languages and systems easier to port to other systems and other hardware.

Antworten

• 24. Apr 2021 - 08:32

Declarative and functional languages have significant advantages over procedural languages such as C++ as they specify what is to be done, rather than how to do it. Strong typing reduces the likelihood of errors, and additionally proof checkers can validate the code.

Program generators also can be used to give greater reliability - and for very large scale projects are used rather than having programmers hand coding and possibly making very dangerous errors.

Antworten

• 15. Apr 2021 - 20:31

To some extent all programming languages are kind of sort of similar - I mean, they all have ways of saying things like "if x equals y then do z", even if the details are different. But no, C++ is not particularly like Python otherwise. C++ is a traditional compiled language. Python, like Javascript, is interpreted (Java is actually kind of middle ground). This ends up making a big difference in the experience of actually writing in and using the language.

C++ is, I would have to imagine, the single most popular programming language in the world for applications like MuseScore - full-scale standalone programs with their own GUI, etc. But it's true that C++, like other traditional compiled languages such as C, is mostly used for this type of application, as opposed to smaller tools or mobile or web apps. That's where you mostly see use of interpreted languages like Python or JavaScript. That's a huge overgeneralization of course, but it's definitely more true than saying C++ is outdated :-).

Bottom line, large GUI-based applications like MuseScore are almost always written in a traditional compiled language like C++. FWIW, Finale, Sibelius, and Dorico are also written in C++.

Antworten

• 15. Apr 2021 - 21:09

I see. Thanks for explaining. I suppose old would be a better way to describe C++; old but still useful. Python is quite a bit newer, I believe. My dad tells stories of college, where he would set up a program on a computer to do an equation, come back after lunch, and find out the general area where that "ball" would have landed. He used Fortran and some variety(ies) of C for the stuff he did.

Antworten

• 15. Apr 2021 - 21:21

"Venerable" rather than "old". Both C++ and Python date from the 1990's and have evolved. C is from the late 1960's, Fortran from the1950's. It was not uncommon in the punched-card era to bring your cards to the computer center and come back later for the printout, but the time delay was not computation, but handling physical media and people.

Antworten

• 15. Apr 2021 - 22:59

C++, Python, and JavaScript were all created within a few years of each other back in the (19)80's-90's. So while C++ is indeed a few years older than Python, none of these are remotely anything like "new". And it is that long history that makes them so popular and useful, with such widespread support across almost all operating systems and hardware.

Antworten

• 31. Jul 2021 - 22:09

Only somewhat. Python is used in machine learning and similar types of regression in the typical python way: Implement cheap things in python, and expensive things in C-Libraries. So we have python modules like tensorflow that offer ML functionality in python, where you can quickly write programs with it. But the whole backend is a C-Library. If you’d implement ML in pure python it would be unusably slow. You could could say: Python is used as a layer to connect components written in C.

Antworten

• 22. Mai 2021 - 20:57

Yeah, it seems a little odd to announce NotePerformer support and then just not add it and then not tell anyone that it's not actually gonna happen until a year later. I'm also very disappointed. A new playback system sounds great and all, but I very much doubt that it's going to have the quality of Noteperformer without spending a stupid amount of time tweaking playback

Antworten

• 31. Jul 2021 - 20:11

I was telling people back when the support was announced that I wasn't sure it was as easy as people thought. The issue is that MuseScore 4 only has VST3 support (no VST2 support) and NotePerformer is VST2 only, with no VST3 support. It likely isn't practical to rewrite NotePerformer for VST3 until Finale and Sibelius support VST3, otherwise it would be like going from developing one product to developing two completely different products. Arne said he was going to try to develop a bridge (a shim) to allow the VST2 NotePerformer to be used in VST3 hosts, specifically for MuseScore, but I'm guessing this was unsuccessful due to the enormous difference between the VST2 and VST3 spec.

Unless a bridging solution can be found, I suspect there may not be NotePerformer support in MuseScore until MakeMusic and Avid add VST3 support into their notation products, which would allow NotePerformer to be rewritten for VST3 and would then work with Finale, Sibelius, Dorico and MuseScore.

Antworten

• 4. Aug 2021 - 21:40

FWIW, this was the original plan but we since Muse has since acquired a similar technology, we felt it made much more sense dedicating our resources to supporting that external plugin - which will be free - rather than one that people need to pay quite a bit of money for.

I'm sorry you felt the need to purchase NP so early. We never anticipated people would do that.

Antworten

• 5. Aug 2021 - 10:52

Go to MuseScore.com and listen to any score and you'll have your answer :D

It is in our interests to provide excellent playback for free because:
1. It means more people will use and enjoy MuseScore
2. It means people interacting with MuseScore.com will have a vastly improved experience when listening to scores.

Incidentally, we've also got VST and VSTi support in MS4, which we will be building upon in later releases. I want to begin building relationships with other free plugins so that users can download and install them too.

Antworten

• 5. Aug 2021 - 11:16

I'm gonna assume that you mean the playback just doesn't sound good right now. Which I agree with if that's the case.

Also, I was impressed because I didn't expect this open source project to be able to also plan plugins when it has to "refresh" the whole software. But seems like I was wrong. Heh.

I mean, even Blender provides the base software for free but some plugins are not made for free in order to support the project's development with money... I think.

Antworten

• 13. Apr 2021 - 08:15

When I'm the customer, or in this case the user, I always tell people who are producing what I'd like to get, "I'm willing to wait if what I'm waiting for is great." Just keep at it guys.
Also, it seems like there should be one more stage between Complete and Ready, and that is Tested. I don't know if it can be done, but third party testers with different platforms should try out the new fixes or features to make sure it's "box-ready," that is, truly complete, ready to ship, as it were.
One other thing: I am currently learning Qt's Quick scripting language to assemble the Ornament Editor that I and others have requested in the past. Is the same scripting language going to be used? If so, will there be any changes to the variables, controls, or UI design for MuseScore 4?

Antworten

• 14. Apr 2021 - 14:43

Sounds very organized and I'm looking forward to the replacement of the 'Synthesiser' window functionality, which always felt somehow a bit odd. Integration into the Mixer sounds like it makes much more sense.

Antworten

• 14. Apr 2021 - 20:15

Great news. Any plans for ornaments (trills, mordents) with accidental in v4?
Also, I'm confused with new work on piano-roll view. Sequencer view should be a better solution than piano-roll view (everything that can be done in piano-roll view should be possible in sequencer view), so there will be no need for piano-roll view any more? Is it just temporary solution? If it is, it looks to me that you plan sequencer view in a far distant future.

Antworten

• 17. Apr 2021 - 00:24

For the internal team, MuseScore 4.0 is mainly about the UI rather than notation, but we may see some notation improvements in a subsequent minor release (4.1 or 4.2, etc.). We might see them sooner if a talented community member steps forward to implement them, but only if they don't involve major changes to the internal model (ornaments with accidentals should be ok in this regard, at least in terms of notation, maybe not playback at first).

Similarly, the full Sequencer view has been postponed for a future release, but if a community member steps forward then we may be able to provide an improved piano roll sooner, which would be the first step towards a full Sequencer later on. The internal team is ready to provide design support to anybody with developer skills who is able to contribute in these areas, or in other areas that we consider important but won't be able to implement ourselves in the near future.

Antworten

• 15. Apr 2021 - 19:35

I hope this is not a "silly question", but the major architectural departures outlined force me to ask it: Will MS4 be able to play MS2/MS3 scores with the current sound fonts? Some of us have put a lot of work into making our scores sound "right".

Antworten

• 16. Apr 2021 - 23:31

FluidSynth will still be available with the default SoundFont (MuseScore General), so most people's score will sound the same, or very nearly the same, as how they sounded in MuseScore 3.

If you opt-in to using the new playback system then your score will sound very different to how it did before. Hopefully it will sound much better than before, but you might find that you need to tweak a few things that you had previously optimized for the old playback system.

If your score used Zerberus (.sfz) rather than FluidSynth (.sf2/.sf3) then you will be forced to switch to FluidSynth or the new playback system, but not many people used Zerberus and the new system will be much better anyway.

Antworten

• 18. Apr 2021 - 04:40

I'm hoping that the new Zerberus sampler/synthesiser and its playback system will allow Musescore users to easily set track voices to separate channels, so we can score pitch bend in one voice while notes in other voices stay unbent. As described here.

Naturally I have the same hopes for VST in Musescore 4.x. I don't know much about VST, but surely it's General MIDI compliant (or follows MIDI 2.0) and would inherently support that. And there are definitely some VST libraries, like those at Iindiginus.com, that I'd love to to purchase and use with Musescore.

Antworten

• 26. Apr 2021 - 03:13

If it is possible...could you PLEASE make the brass section sound smoother than the way it does at the moment esp. the trumpet? It is hard to come by free sound founts, less having one where the brass section is a little smooth.

Antworten

• 28. Apr 2021 - 14:25

I use a Chinese system. I downloaded a compressed file of the latest version of musescore4 from the development page. After running the software with NVDA reading software, I can’t perform any operations and there is no way to operate it.

Antworten

• 28. Apr 2021 - 14:27

I use a Chinese system. I downloaded a compressed file of the latest version of musescore4 from the development page. After running the software with NVDA reading software, I can’t perform any operations and there is no way to operate it.

Antworten

• 6. Jun 2021 - 20:17

Way off topic, but you have to be Matthew's brother... I was wondering, so I looked you up on Facebook and saw he was one of our two mutual friends. He visited me in Nashville a few years back when he had a house concert in town. We met at U.M. many years ago. I think I was the T.A. of his freshman theory class. We worked on a project together at a small studio a few years later. Great sense of humor and a heck of a musician. Love that guy.

Antworten

• 30. Apr 2021 - 06:40

I'm curious as to how things are going to work for microtonal composers like me. In MuseScore 3, I have to use the inspector to manually tune individual notes, and I don't know if this is going to be carried over from MuseScore 3, or if new systems for dealing with microtonality will be considered later on.

Antworten

• 30. Apr 2021 - 09:59

Yes and yes. Inspector tunings (or a very similar system) will be carried over from MuseScore 3 to the initial release of MuseScore 4.0. A better system will be considered later on, possibly in MuseScore 4.1 or 4.2, but probably much later in the 4 series given the number of other things we have planned. You'll probably find that you get a nicer way to do it manually (e.g. via Piano Roll instead of via the Inspector) before you get a way to do it automatically based on special microtonal accidentals.

Antworten

• 1. Mai 2021 - 16:20

Hmm... If the Piano Roll will be the better functionality for later, then I just hope I get to divide the octave into as many as 159, seeing as I tend to use 159edo a lot- I'm not kidding, I've actually written songs using that many notes per octave. As for accidentals, I do have some ideas for a system planned for 159edo, but I'd have to talk to someone about how to make those.

Antworten

• 30. Apr 2021 - 22:04

How wonderful... all those contributions make me so ashamed of myself for not taking part in any of those projects out there... At least I should put at good use Musescore and recreate all of Stravinsky's rare-or-not scores with the new fonts teehee.

Antworten

• 2. Mai 2021 - 22:24

I am so happy to hear about so innovative Musescore future step, GREAT!
I would like to ask if there will be Linux version and is it possible to implement "Live notes input"? Playing on the keybord puts notes into the score live. This is verry helpful function and I miss this option.
Anyway, I am waiting for new Musescore and I'm looking forward.

Antworten

• 3. Mai 2021 - 10:46

Do you mean you can play and the notes will be in corporated into a score, or alternatively that you can also "play along" with a score - for example in a live performance? I think it is possible to do the first of these already, though the results if you're trying to input a score will depend on how accurately you play.

Antworten

• 3. Mai 2021 - 04:13

“This will not be packaged with MuseScore but can be downloaded and activated (for free) once the application has been installed.”

What will/is the workflow for packagers supposed to be? I’d definitely want to ship things like that as Debian packages so they install without getting online (and tracked). Same for the effects.

Antworten

• 16. Jun 2021 - 10:23

Installing optional add-ons requires an internet connection and add-ons may only be installed directly through MuseScore online services (as is currently done for Resource Manager).

It will not be possible to make these available through any alternative channels or means of installation.

Antworten

• 17. Jun 2021 - 11:42

There is no libre MuseScore 4 vs. non-libre MuseScore 4, only a single application distributed under GPLv3 license.

Optional add-ons may or may not be compatible with GPLv3.
It will be up to the user to choose to install any add-ons, or not, just as it happens now.

Antworten

• 17. Jun 2021 - 12:55

> " just as it happens now"
Except for the part where you stated "online via MuseScore resources only"..

EDIT: to clarify, I'm not stating that there shouldn't be add-ons which are non-free/non-libre (even non-gratis) and which can be delivered via MuseScore services exclusively. I'm stating against the fact that you'd limit add-ons to those MuseScore service provided ones; which is taking a step backwards from the current MS3 possibilities.
They don't have to be (and shouldn't imho) mutually exclusive.

Antworten

• 17. Jun 2021 - 13:14

My point was simply that the optional add-ons created and released by MuseScore BVBA will only be able to be downloaded and installed online visa MuseScore resources.

This comment was in response to request to ship the optional playback add-on for MS4 as a Debian package, which is not an option as it will not be open source and will only be distributed through MuseScore.

Anyone is free to create their own extensions or plugins and distribute them however they see fit (including through MuseScore). Any self-made/self-distributed extension is installable by simply dragging it onto a MuseScore window.

Antworten

• 16. Jun 2021 - 20:29

Let's hope the delivery process works better than the one from MS3 currently... (failed download messages anyone?).

Also.. how will this deal then with currently already existing custom user muxts? Will you automatically provide hosting and distribution for all of them?

Antworten

• 5. Mai 2021 - 09:46

I can only say that I'm very excited about the date of release and I think this is a step in the right direction. The only thing that I would like to change in musecore is adding a professional layout to the score. Meaning having a frame decoration and a template for an opening page introduction and the like.

Antworten

• 5. Mai 2021 - 14:12

Musescore gives you the possibility to add images, I don't know if it lets you add frames though. But with small effort, you can easily make a nice opening page with Inkscape or illustrator or any such programs.

But yes, maybe that's a good idea to add.

Speaking of professional stuff, I've seen some "engravers" complain about how NO composing software (except the old style ones like SCORE) seems to be great, by default, for making "classic looking" scores, more specifically, some lines seem to be really thin, for what companies engrave usually. I personally feel like it has been improved with the last update, but it still seems like an "incomplete" side.

Of course everything is customizable but the thing is to avoid touching those if possible. Perhaps I need to open a new thread for it? Or there already is one?

Antworten

• 6. Mai 2021 - 17:47

Even Elaine Gould recommends (in her keynote of the engraving conference last year) to do the title pages in a different program then combine them for printing only. Doing this in notation software, which is absolutely not up to the task of the very detailled requirements (it can’t even justify text! MS Word 4 for DOS could do that in the 1980s!) and to use the right tool for the job is necessary, otherwise you have one tool which sucks at all tasks.

Antworten

• 5. Mai 2021 - 17:12

Pardon me for asking a question which is probably a bit ignorant. I'm not a musician, but my wife is (shameless plug http://pamelayork.com ). For years my wife has used Finale primarily for transcription purposes. Is Musescore comparable to Finale in being able to attach a keyboard, play, and have the notes show up on a score? I've moved the whole family to Linux sometime ago, but we need to keep her on Windows, because she needs a good tool for musical transcription. If there was a option for musical notation software for her to use on Linux, then I would probably move her over since it would be easier for me to administrate all the home computers that way. Thanks!

Antworten

• 7. Mai 2021 - 19:36

Before you drift off to another part of this forum I would suggest that it may well be possible, though depends exactly what you want to do and what hardware interfaces you use.

Why not just download MS (to Windows) and spend an hour or two trying it out? I have had several keyboards and other kit all working - some with their own inbuilt sounds, and also with the computer sounds. If you have the connecting cables and interfaces, or suitable Bluetooth interfaces, you may be able to get something working in an hour or two. If it does what you want in Windows, then see if it'll migrate as you hope to Linux.

If there are problems they are quite likely to be related to the connections - which can be somewhat iffy - though I can't say how things will work with Windows as I use Macs mostly now.

It's possible that for quality or other reasons it may not compare with Finale, though I think it's improving all the time. Depends if it delivers what you want.

Antworten

• 10. Mai 2021 - 20:38

I am writing for Concert band, Orchestra and Chorus, and I’m really interested in the Spitfire instrument libraries (although they are expensive). Can I use them with Musescore?

Antworten

• 17. Mai 2021 - 18:17

The both of you please note that there’s a distinction between free/gratis (e.g. Pianobook) and free/libre (e.g. MuseScore). It’s unfortunate that the English language, unlike so many others, doesn’t have this distinction implicit in the wording, but it’s important.

Antworten

• 16. Mai 2021 - 00:33

Depends. GPLv3 is definitely less free than GPLv2, but it’s still no less Free Software and Open Source Software than MuseScore 2 and 3 were. But it’s not yet finished, who knows what will be done… there seems to be a movement towards offloading prior core functionality into “downloadable addons”; these may or may not be Free, and this certainly seems to imply “phoning home”, which violates privacy standards. But we’ll see what they deliver when they deliver.

Antworten

• 16. Mai 2021 - 08:30

GPLv3 is Free Open Source Software. That is all that matters in this context.

I don't think there's anything that was a core feature in MS3 that will be demoted to an addon in MS4.

And I don't know why you think they won't be free - if there ever were addons that weren't free they would probably be for things like Noteperformer, or commercial VST effects.

How does having downloadable addons violate privacy standards?

Antworten

• 16. Mai 2021 - 14:06

This may remind of Blender. One of the reason it goes strong is that it's free, but some add-ons are not, so that people can pay for them and help the development of Blender continue.

I don't think there's any other project doing it this way. Most usually setup a page for donating. Maybe blender has one too.

Antworten

• 17. Jun 2021 - 17:17

Which is why the word “free” should be avoided and “libre” vs. “gratis” should be used. (English is unfortunate in that “free” can mean either; in German, we have separate words for this, though “libre” translates into the literal vocabulary for “free”.)

Antworten

• 17. Mai 2021 - 16:00

Will the alpha release be able to be accessed by everyone? Or just a select few? And if it is a select few, is there a way for me to be one of those select few?
Also, how will VST support work in MuseScore 4? For example, some libraries only have select articulations, like legato and staccato, and if you would want to accent the note, would it not work or would MuseScore 4 be able to recognize when you want a note to be accented, just play the legato note louder and a little bit shorter than usual?

Antworten

• 19. Mai 2021 - 15:53

I could actually imagine an official alpha program with feedback forms and so forth that would be by invitation.
Not sure if that will be a thing or not, but either way, anyone cat any time can install a nightly build - you can even do that today if you like, although it largely won't work yet. So even if you're not part of any "official" alpha program that may or may not happen, you would be able to install the nightly build on that day just as surely as you can on any other day, and test for yourself.

Antworten

• 24. Mai 2021 - 15:51

Lots of VSTs need Kontakt to host their plugin or whatnot, and I was wondering if Kontakt would be able to be used on MuseScore 4 as I haven't found an answer to that yet, and if not, many sound libraries wouldn't work which would be a little disappointing. Thanks to anyone who has information about this.

Antworten

• 24. Mai 2021 - 19:25

I just responded to your dedicated thread but I'll paste my reply here to.

"Your terminology is a little mixed up. Kontakt (both full and player) runs as a VSTi/AUi/AAX plugin or standalone application. Sample libraries made for Kontakt are NKI files, they are not VSTs.

If Musescore is able to host VSTi or AUi plugins then I see no reason why it won't be able to run Kontakt and therefore Kontakt based libraries."

Antworten

• 6. Jun 2021 - 16:30

quick question , could you please add a way to use kontakt and other plugins for musescore ? since you're taking away the ability to add soundfonts , i beg for you to please add a way to use kontakt and other vst plugins like izotope and stuff- thank you ! :]

Antworten

• 8. Jun 2021 - 02:01

Okay, I have not one but two feature requests. The first is for MPE support (see https://en.wikipedia.org/wiki/MIDI#MIDI_Polyphonic_Expression), while the second is for effect automation. Oh, and I have a third request related to the piano roll functionality- the ability to support Equal Divisions of the Octave as large as 171. This requires piano roll functionality to be a bit different from standard- or at least that seems to be the case. I'm requesting these things because although I've largely been inactive on this site, I've actually been using MuseScore for a while now, and since I've gotten into microtonality, it would be great to see stuff like this. I should also mention that, as of right now, when I try and export microtonal stuff to a MIDI file, all the microtonal stuff is completely wiped out in the process.

Antworten

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