The MuseScore Symphony (Symphony in D minor) now complete and online

• Sep 7, 2016 - 20:19

The final movement of my Symphony in D minor, Alla breve, is up on YouTube. I just now realize I forgot to post to the forum when the 3rd movement, Scherzo, went online in May. Here are the links to both:

  III: Scherzo
    (You may want to raise the volume of the Scherzo. It's a bit soft.)
  IV: Alla breve

I strongly encourage checking these out as examples of what can be accomplished with MuseScore playback when playback is handled by an external sampler and audio tools. The results are very good. I can't find anything else of comparable quality produced with MuseScore online. (The first two movements of the symphony were produced either using MuseScore's native fluidsynth playback [1st movement] or a combination of native playback with selected instruments being handled externally [2nd movement]).

All four movements of this compact symphony (15 minutes) were composed directly onto the score without the aid of a keyboard, either midi or acoustic, and represent the culmination of five years' worth of work exploring Linux audio's applicability to the composition of orchestral music.

My goal was to assemble the best virtual orchestra possible from non-commercial soundfonts, and to set up a MuseScore template for orchestral scores that was flexible enough to be used for everything from a small chamber orchestra to a full, winds in threes Romantic score.

Furthermore, thousands of hours of testing and experimentation went into selecting and implementing the best and most reliable open source audio processing software for equalization, spatialization (panning and reverb), and mastering. Here's what I'm using:

  • Midi/audio connector: JACK
  • Session manager: non-session-manager
  • Score writer/midi front-end: MuseScore
  • Sampler: linuxsampler
  • Plugin host and JACK patchbay: Carla
  • Equalizer: LV2 eq10q
  • Chorus: Calf Multi-chorus
  • Mixer and spatialization console: non-mixer
  • Reverb: jconvolv
  • Mastering: JAMIN

There are significant weaknesses in most of these components, from truly awful user interfaces to inexplicable crashes, but once everything's set up (vertiginous learning curve), you can compose directly onto the score in MuseScore and preview the results instantly, fairly certain that they accurately portray how the music will sound when played by a real orchestra. When done, you can go back and do the note-by-note tweaks necessary to draw out a more sensitive musical performance.

I can't count the number of times it has been said on the MuseScore forums that MuseScore is a notation program (as opposed to a score-centric DAW front-end). Clearly, the people saying so don't live in the same universe as I, as the audio of my Symphony in D minor proves. When MuseScore is decoupled from its internal synthesizer (fluidsynth), it already acts as a DAW front-end by sending midi signals to an external sampler connected to a sophisticated audio chain. It just doesn't do as good a job as it could.

Focusing soley on the midi side of MuseScore, where its only weaknesses with respect to acting as the midi front-end of a DAW reside, I have isolated exactly three, very specific areas where MuseScore's limited midi-sends interfere with or ruin accurate playback. Just about every other playback issue can be fixed further down the audio chain, or faked with a creative use of what MuseScore already provides.

  1. It must be made possible to swell or decrescendo through held notes. It is a basic and indispensable building block of musical performance, particularly in orchestral music, and it simply cannot be faked not matter how skilled one is with MuseScore. If just this were fixed, MuseScore would be 90% complete with respect to its midi sends.
  2. Note-by-note control of gate off-times, which were available in the previous release (1.x) of MuseScore, must be returned. Players breathe and pause between phrases; bows change direction. These require that some notes be shortened fractionally, the amount dependent upon context. This can be somewhat faked, but the time and effort involved is enormous.
  3. It is utterly essential that staves be provided with more than one midi channel, the number being settable by the user.

    I've raised the issue of multiple channels per staff more than once, but I feel like a voice crying in the wilderness. The Change Instrument dialogue is NOT satisfactory for this purpose! In the Alla breve movement, I'm constantly changing between solo and section woodwinds, some of the single staff polyphony requires a separate channel for each part (if a part, moving in quarter notes, touches or crosses over a whole note in another part, the whole note ceases to sound), the brass requires several changes of soundfont to accommodate the timbral differences between forte and piano, the strings sometimes need layering to make them more brilliant or mellow, etc. All of these require having extra channels on each staff.

    You can edit .mscx files by hand to add extra channels, which is what I did for my massively complete orchestral template, however I believe this should be doable from within MuseScore. The number of channels and their names could easily be set up in the Instruments dialogue, and would be reflected in the choices presented in the Staff Text Properties dialogue.

I hope that my many years of working with MuseScore, an entire YouTube channel devoted to MuseScore projects (audio and scores), and an original symphony composed directly into MuseScore will establish my credentials sufficiently for the above to be taken seriously. No more sidestepping playback, or rather, midi failings with the excuse "it's a notation program". I believe I've proven otherwise, incontrovertibly.


#1 is obvious enough, and indeed may well be addressed (see below). #2, to be clear, is already possible via the piano roll editor, but could indeed be made easier / more powerful. #3 I don't really understand, however. Sounds like you are proposing a new feature just as a way to work around *other* issues (eg, the bug with multiple voices cutting each other off). If the other issues were resolved, I'm not sure there would remain a case for multiple MIDI channels for a single staff. In particular, surely you don't literally need a separate MIDI channel just to change instruments - allowing a separate *mixer* channel that still transmitted on the same MIDI channel (a la trumpet normal/muted) should suffice? Indeed, the whole problem as I see it with the current instrument chane model is that *too many* such channels are created, when you really just need the two. If I am misunderstanding, perhaps you could start a new discussion focused on this specific topic?

BTW, no doubt MuseScore *can* be used for purposes other than notation, that's not in question. But it's *intended* purpose remains focused on notation, so hopefully you can understand why that is where most development effort remains focused. See, however, the work that was undertaken for a future release as part of GSoC:

In reply to by Marc Sabatella

On #1, I've been following the thread you cited. I included it in my short list of required fixes because it's a biggie.

On #2, the piano roll editor is next to useless in its present state. Can you imagine having to use that awful thing to edit hundreds of notes? You're right, it can be done--at the risk of blindness and a positively murderous rage resulting from frustration. :) Definitely not the way to go. The most sensible place to make off-time adjustments is on the score, which you can read and make sense of, unlike piano roll notation which provides no useful information about the structure of a score, and thus no easy way of locating notes in need of tweaking. Was there a technical/programming reason on- and off-times were removed as controllable parameters from inside the GUI? If not, they should be re-implemented.

On #3, I've already raised the issue and explained it, and gotten the same response from you, Marc. I really don't understand why something so obviously useful is so hard to get across. Perhaps it's a terminology problem? Or perhaps that your thinking is too closely focused on the GM soundbank standard? I'm suggesting these because of this sentence: "...surely you don't literally need a separate MIDI channel just to change instruments - allowing a separate *mixer* channel that still transmitted on the same MIDI channel (a la trumpet normal/muted) should suffice?"

Trumpet normal and trumpet muted are not transmitted on the same MIDI channel. The two mixer channels represent two separate, uniquely identified MIDI channels, as I know well from wiring them up to linuxsampler. Trumpet normal has a unique channel number (say, 7) that I hook up to my trumpet normal samples, telling linuxsampler to listen for signals on channel 7, and trumpet mute has a unique channel number (in this case, 8) that I hook up to my muted trumpet, telling linuxsampler to listen for signals on channel 8. The Staff Text Properties dialogue and the xml file confirm that these are, indeed separate channels.

Trumpet is the perfect example of why we need to be able to assign multiple channels (a la Trumpet) to a single staff. You don't write a separate staff for muted trumpet parts, you write con sord. over the trumpet staff and assign it the "mute" channel using the Staff Text Properties dialogue. It would be counter-intuitive to the way musicians think to use the Change Instruments dialogue for this purpose because you aren't changing instruments. The same, of course, applies to Strings staves, which automatically get three channels: normal, pizzicato, and tremolo. You don't set up separate staves for pizz. strings; you write "pizz." over the staves and switch to the pizzicato channel with the Staff Text Properties dialogue.

Now, if your thinking is limited to the GM soundbank standard, there's no need for other instrument staves to have more than one channel associated with them. Problem is, the GM standard is woefully inadequate for substantial orchestral work because the soundbanks don't have slots for all the required instrumental sounds. For example, trombones are played with mutes, but there's no GM slot for "muted trombone". And trumpets themselves are played with Harmon, straight, cup, etc. mutes--so "muted trumpet" isn't sufficient. And strings--hell, what can you do with just "normal" (which could be anything from under-one-bow legato to markedly détaché), pizzicato (is that regular pizz., left-hand pizz., or Bartok pizz.?), and tremolo? What about sul tasto/sul pont./con sord./harmonics/etc.? Or French Horns--bells up, stopped. These aren't unusual effects, they're a routine part of what composers have been calling for for centuries.

The only way to render these timbral changes is by using a different soundfont, which entails a tailored arrangement of channels and samples that removes any need whatsoever for thinking in terms of the GM soundbank standard.

The changes have one thing in common: you indicate them over the staff of the instrument to which they apply, exactly the same way you indicate "con sord." over a trumpet part. You don't set up separate staves to accomodate them, and you don't "change instruments" (as far as the score is concerned).

So how do you accomplish it in MuseScore? You can't do it with the Change Instrument dialogue because the list of choices it presents is GM standard-based and doesn't contain the very sounds you're looking for. Besides, in addition to calling up the dialogue and selecting the "new" instrument, you have to erase the word "Instrument" and type in what you want instead, possibly having to change the text parameters as well, which would get very annoying after a while. More significantly, every invocation of Change Instrument creates a new Mixer/MIDI channel. Every time! Six instances of "Muted Trombone"s (were such possible) would result in six new channels. Even worse, Change Instrument alters the channel assignment of all instruments that come after it. If you're working with an external sampler--virtually a necessity for substantial orchestral scores--that means re-wiring everything each time you use Change Instrument (assuming you're composing, as opposed to merely transcribing), unless you've mapped out your as yet unfinished new composition perfectly in advance. Even if you have, the decision to add or remove even one of your alternates means re-wiring.

The solution to this problem is blazingly simple but nowhere documented: 1) before you start note entry, save your score as an .mscx file; 2) open the .mscx file; 3) locate the staves where you'll need to switch from one instrument sound to another; 3) add as many xml <Channel name="name"> stanzas as you need, choosing names that will mean something when you call up the Staff Text Properties dialogue.

A simple, real-world example of this would be setting up Flutes such that you can switch between a due and solo, and having a third option that allows you to call upon a more expressive soundfont for passages written specifically to feature the principal flautist. This is a setup I use frequently, with demonstrably better, more accurate, and more realistic playback than relying on the GM standard. My three channels are called normal, sect., and alt. Once flutes are set up this way, all I have to do to switch to, say, a due is add Staff Text (Ctrl-t) that says "a due" and call up the Staff Text Properties dialogue, which looks like this, to change to the appropriate channel:

Flutes Staff Text Properties dialogue

The advantages are obvious: non-fussy text entry, musical directions in the score that are properly reflected in the playback, and no "new" channels being created every time you switch back and forth between solo and a due, thus a smaller mixer window and no re-wiring.

My repeated suggestion that the ability to add (and name) multiple channels to staves be part of the GUI, rather than something only done by editing the .mscx file, is based on four distinct advantages: 1) the Edit=>Instruments dialogue is the logical place to do it; 2) it relieves non-technically-oriented users from having to edit an .xml file; 3) in the case of changing your mind about the number of channels you need allotted to a single staff, you don't have to close the file in MuseScore, open and edit the .mscx file, then re-open it in MuseScore; 4) other than re-designing the Edit=>Instruments dialogue somewhat, it would be trivial to implement, since all that's required is adding simple .xml stanzas to the .mscx file. Come to think of it, it would mean you could use the .mscz compressed file and never have to worry about saving as .mscx.

I really can't make this any clearer: accurate playback requires that playback do what the score says, so if you say, of first violins, con sord., you need to tell that con sord. to switch to the "violins with mutes on" channel. That can only be done if the first violin staff has a channel set up for muted violins. FWIW, I generally use five to six channels per string part to handle all the eventualities.

Attachment Size
channel-dialogue.png 24.29 KB

In reply to by Peter Schaffter

Regarding #2 - the reason, as I understand it, that note on/off settings were removed from the main GUI is to accomodate things like tremolo and ornament playback. The implementation of these means that a "note" doesn't necessarily have but a single MIDI event, but might well have several, and there was no clear way to have one settings for the note as a whole apply meaningfully to the indepedent MIDI events that make up the note. The piano roll was intended in part, I think, to make it possible to edit those individual events. But indeed, it's not very fun.

Regarding #3, OK, thanks for the correction regarding the fact that current separate MIDI channels are used for trumpet normal/muted. But to be clear, that's not *necessary*, right? I mean, it would work exactly as well if they used the same MIDI channel, would it not? Meaning, a solution that simply modifed the Instrument Change (which *does* create a separate Mixer channel and thus gives you full access to everything you need for selecting sounds as far as I can) to allow you reuse that channel for subsequent changes would be completely sufficient as far as I can tell. So for instance, you might add the instrument change text (which of course could be renamed to "sound change" if you prefer), and have the Change Instrument dialog be modified to allow you to select from among the existing Mixer channels or create a new one.

Note BTW you can add custom text elements for a cusotm palette; no need to use the predefined "Instrument" text.

In reply to by mrobinson

I don't post my original MuseScore documents since many of them, including movements of the Symphony, suffer from the "wandering hairpin" problem. Plus, of course, playback from them is well-nigh impossible without my audio setup and soundfonts. If you're interested in PDFs of the score, they're available from my website at // , or will be once they propagate through the system.

... the actual MuseScore files ...

I am right now very-avidly studying ... and, therefore, seeking out ... symphonic scores, most especially if they are already in MuseScore format.

I am perfectly ready to accept that the "playback" of these files will not match [YouTube].

I am also prepared to spend money.

I've taken the time to listen to your entire symphony, and I am impressed not only by the sound quality you have achieved in the videos, but by the music itself. This is an excellent piece of neo-classical composition, and you have every right to be proud of it. If my company published classical repertoire (we don't; pre-classical transitional works from 1735-50 are about our limit), I would be happy to consider this symphony for our catalogue.

As to requiring MuseScore to provide this level of playback quality out-of-the-box, I am somewhat less sanguine. Yes, it would be nice if it were practical, but the question must be asked: to what end? In the world of music publishing and performance, digital playback is a convenience, not a pre-requisite. Conductors and editors can (or should be able to!) look at a printed score and hear it in their heads without needing to hear an audio file. If you were to send a PDF of your score and an MP 3 derived from the standard download to a music publisher, the editor-in-chief of any professional publishing house would be able to evaluate the musical worth of the piece without needing the audio refinements you have worked so hard to achieve. Yes, it is possible that an editor might be swayed by a really good audio file if the music itself were less than compelling, but that is not the case for your symphony, or for most other new works worth publishing.

In reply to by Recorder485

I think that it’s clear that the author wanted to demonstrate that it could be done, using MuseScore and other open-source software. The point has been superbly demonstrated: he did it.

A software product always benefits, in the long run, by the people who “push the limits” of what it can do ... and then give detailed suggestions for improvement that are born out of that experience. I looked around for a web-site forum that details the entire project (hint, hint ...) but to my surprise I have not yet found it.

The power of playback is easily shown in the video itself, where the musical score is displayed along with the music and the measure now being played is highlighted. It would be, among many other things, an excellent teaching tool, because the music is being presented in two ways and in real time.

I generally agree that it would be valuable to MuseScore for suggestions such as multiple channels per staff to be implemented. (I plan to check-out the source code repo in a few days and have a look around. This is my bailiwick.) Although playback is not the product’s primary focus, I also think that “the preparation of a musical score, today,” consists of more than just paper. In truth, we are preparing an XML file, which can have a great many uses, and we should be able to include “metadata” (for lack of a better word ...) that might or might not appear on a printed page. While we do not have to hold ourselves to perfect playback, I think that a composer should be able to manipulate everything ... within reason ... that the XML affords him, not just stave-paper.

I also think that this symphony is of excellent and enduring quality, and that it should be published. I would love to someday hear an orchestra perform it.

In reply to by mrobinson

Here's a sentiment similar to yours expressed by the score's creator:

For various technical details, he's also posted here:


P.S. I've been intrigued by Mr. Schaffter's resolve since the time he employed guitar bariolage in a score, and strove for a decent sounding playback. Re:
After his successful attempt, I told him his "work was done".
Who'd have thought...

In reply to by mrobinson

You're absolutely right about animated scores with good playback being an excellent teaching tool. I learned orchestration the hard way, in the pre-digital age. While I don't begrudge one bit the discipline this imposed, man, what a difference it would have made it I could have learned orchestration with the help of a digital orchestra! I would still have had to plough through Piston and Rimsky-Korsakoff and Berlioz, but what they have to say would have been so much more meaningful at the time if I hadn't had to wait my turn with a practice orchestra to discover the meat on the bones of their indispensible works.

I, too, wouldn't mind hearing the symphony performed. Any takers? :)

In reply to by Recorder485

Oh, I wouldn't even begin to suggest that MuseScore should, or could, provide that level of playback quality out-of-the-box. What I do feel is that the midi events it sends need to be sufficiently complete and user controllable such that quality playback can be achieved by plugging it into a good external audio chain, basically what I've been working towards. All that's required of MuseScore for this is good midi handling, nothing more.

It's funny how when you put on a different pair of analytic glasses, you see things completely differently. You're a publisher, so for you, quality playback is an adjunct to submitting a score to a publisher. I'm a composer, with works that are never likely to be performed, let alone published. The digital revolution has made it possible for me to create performances of these works that I can share with the public, so playback isn't an adjunct, it's the whole point of the exercise. MuseScore already makes it possible to create exceptional scores for printing, but they're meaningless to people who can't read music. What means something is listening to the music, rendered as accurately and as sensitively as possible by a virtual orchestra. Perfect realism isn't, of course, possible, but a good simulation is more than enough to move listeners, and to clue them into your musical thinking.

Interesting that your company sticks to the south side of 1750. When I conceived the Symphony in D minor, I was thinking just a little north, around 1750-1775. Sort of Mannheim with vestigial traces of the Baroque.

In reply to by Peter Schaffter

It's funny how when you put on a different pair of analytic glasses, you see things completely differently. You're a publisher, so for you, quality playback is an adjunct to submitting a score to a publisher. I'm a composer, with works that are never likely to be performed, let alone published.

Well, I'm a composer, too, and have been around too long in too many different capacities to have any illusions left about the music business. So I do indeed feel your pain about the difficulty of getting serious new compositions performed and hearing them played by real instruments.

But even as a publisher, I must admit it would be a nice bonus to have decent-sounding playback for adding audio samples to our website. I know the scores for most of the repertoire we publish, so I can indeed hear it without needing a digital playback, but approximately 60% of our market is composed of amateurs who can't do that, and a really good-quality audio sample would be an excellent selling tool.

It is indeed useful to swap 'glasses' as you say. Here's hoping that your hard work in doing this will lead to improvements that less technically-expert users can eventually profit from.

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