Our Progress on MuseScore 4

• 12. Apr 2021 - 13:56

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.).


The single largest piece of remaining work relates to playback. First, we are replacing the Zerberus sampler/synthesiser with a new (much better) playback system that we have been developing. This will not be packaged with MuseScore but can be downloaded and activated (for free) once the application has been installed. Until the user installs our new system, the default player will still be the soundfont currently packaged in MuseScore 3. We will create a separate detailed post about this shortly.

Since we have implemented VST3 and VSTi3 support, this has necessitated an up-licensing to GPL3. As a consequence, 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.


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.


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)

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


Antwort auf von umutkorkmaz

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?

Antwort auf von Marc Sabatella

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.

Antwort auf von umutkorkmaz

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.

Antwort auf von Marc Sabatella

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.

Antwort auf von Tantacrul

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.

Antwort auf von Tantacrul

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?

Antwort auf von Marc Sabatella

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.

Antwort auf von William Halsted

"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.

Antwort auf von William Halsted

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 :) ...

Antwort auf von William Halsted

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.

Antwort auf von BSG

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.

Antwort auf von BSG

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++?

Antwort auf von William Halsted

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.

Antwort auf von William Halsted

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).

Antwort auf von William Halsted

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).

Antwort auf von William Halsted

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.

Antwort auf von William Halsted

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".

Antwort auf von Joshua Pettus

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?'

Antwort auf von rocchio

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.

Antwort auf von 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.

Antwort auf von yonah_ag

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.

Antwort auf von rocchio

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?

Antwort auf von William Halsted

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.

Antwort auf von BSG

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!

Antwort auf von William Halsted

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".


"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.

Antwort auf von BSG

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.

Antwort auf von dave2020X

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.

Antwort auf von William Halsted

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++.

Antwort auf von Marc Sabatella

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.

Antwort auf von William Halsted

"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.

Antwort auf von William Halsted

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.

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?

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.

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.

Antwort auf von hstanekovic

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.

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".

Antwort auf von BSG

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.

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.

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.

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.

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.

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.

Antwort auf von X-Watcher

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.

Antwort auf von shoogle

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.

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.

Wait, why is the major announcement after the stable release? The stable release is not the "first official" Musescore 4? I'm not sure how to explain that..

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.

Antwort auf von ficmarcin

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.

“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.

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.

Antwort auf von Roieh123

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?

Antwort auf von Iothes

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.

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!

Antwort auf von aaylnx

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.

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?

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