MuseScore 2.2 unison fix caveats -- don't use single MS organ.

In short, if you want to render keyboard (including organ) music on MuseScore, the new fix is a vast improvement.  For rendering on a VPO, it is but a significant improvement with new traps.  Because MS will now correlate apparent unisons on multiple tracks/staves,  and restrike sounding notes, staves destined for different manuals will interfere with each other if expressed in MuseScore as “the same instrument”, e.g., the 3-staff grand-staff "MuseScore organ"  This extends to the pedals as well (where the performance technique of re-striking would be highly inappropriate).  Nonetheless, this behavior is perfect for the 2 staves of a harpsichord or pianoforte.

For multiple staves destined to the the same VPO manual, this is better than before, except that it may interrupt the pedal, and even though you may route the staves to different places, you can't undo what MuseScore now does.

But for 2-manual-and-pedal works, esp. with the left-hand in Alto/Tenor register (e.g., BWV 654, 659), notes in the left hand will cause restrikes of the right, which is very wrong, and the left-hand note (if shorter) won't sound at all (which, for 2 manuals, is wrong).

The solution here is, as proposed in one of my first postings here for simulating organs with other instruments, to set up 3 staves for violin, violin (or viola), and contrabass, and change the instruments to organ, organ, and organ (or don’t – three plenum organs won’t render that texture well!), and brace and measure-line-extend them appropriately.  Just don't use the "MS Organ" on a grand staff.

While that will work perfectly for "2 manual and pedal" chorale preludes, MuseScore then will not "catch" unison collisions between right and left hand when both hands are on the same manual, which you will have to manage as heretofore.  But voice-crossings/unisons in a single hand will be handled beautifully and automatically (if you agree with the re-strikes; if not, do as heretofore).
If you are preparing a large, post-Baroque multi-texture organ work, you'd better go for the three-staff option and manage things very carefully yourself.

It would be better if MS had a "never restrike" option and a 3-channel organ.  Violins have three channels (normal, pizz, sordino). Why not organs?

Add your thoughts
a month ago

MuseScore 2.2 -- a major fix (unison collisions) and a new trap (breath/pauses).

MuseScore 2.2.1, just released, at long last fixes the unison-collision bug, refraining from releasing coincident notes in a single channel until the end of the last (also, when the coincident notes do not start together, the tone is now re-struck when later avatars start -- this may or may not be what you want, and is likely to change). It remains to be seen if there are bugs/problems, but this looks pretty good.  Of course, it cannot know about differing staves on different channels that you route to the same VPO manual, and care is still required there.  But that's a weird thing to do (i.e., not on the same channel in the MuseScore original, but you might have 2 organ manual staves that are sometimes on the same manual and sometimes not; see the next post about the 3-staff organ).

A solution was also implemented for "breaths/caesuras/pauses not appearing in MIDI files".  Because there remains no MIDI representation for this, MuseScore now inserts into the MIDI spurious measures with very rapid tempi if you use such; while this creates exactly the right sound effect on rendering on a VPO, including synchrony with MuseScore for merging, it plays havoc with measure-counting.  If you don't use MIDI tools that traffic in measure numbers, such as mine, this fix is for you. But if you do, either continue to abstain from (active) breaths/caesuras/pauses, substituting any of the kludges described in this forum, or learn how to "adjust" measure numbers to compensate – not easy or pretty.

For a demonstration of the problem, compose a short file with a playing, non-zero pause between two notes, export to MIDI, and open that new MIDI file in MuseScore. The issue will be obvious.

Bravo to the MS team, particularly mirabilos , for fixing the long-standing unison collision problem (I did cooperate with him a bit).

Add your thoughts
a month ago

Another phrasing technology: Cruel exploitation of MuseScore articulations.

As is known to everyone here, MuseScore (MS) lacks inspector controls or context menus to adjust the articulation of notes. Many other score editors have such, but the designers of MS assert that it is “not a performance system”. The known methodologies for controlling articulation are all inadequate: the crash-prone, no-see-score "Piano roll editor", MIDI or other tools outside of MS whose work can't be saved with the score, or hidden "execution tracks" duplicating the score with tiny rests inserted as needed, defeating the expected WYSIWYG behavior. And this applies as much to VPO-destined scores as to any, where the impact might even be deeper because of the otherwise excellent quality and realism available to VPO's, which ARE "performance systems".

But I have found a new way. Listen to this completely-phrased Hauptwerk-rendered score (just enhanced this way): . The secret here is to use (or, rather, abuse) the "Articulations" provided by MS, in this case on a hidden track so you don't see them. You may already know that the "staccato" dot means "cut back note by 50%". And "staccatissimo" (the sharp tick) means "Cut it down to 33%". It turns out "portato", which does not see much use, cuts to 67% (i.e., down by 1/3), and is ripe for exploitation. You can try putting this on notes after which you want a phrase break, and you'll soon find that 67% is usually too short (i.e., too much "cut-back"), but for the most active tempi. You can change this percentage, which is happily stored per score, by editing the .mscx (tutorial URL below). The Largo above sets it to 95%, that is, 5% of "portato" notes are shaved off, and the result is impressive. The correspondingly faster "Vivace" sets it to 80% -- experimentation is necessary for each score. Do listen to that (MS) performance, too -- the portati (although the hungry prefer "portatoes") are visible there in the score.

Promised tutorial (which sort of repeats most of the above, but shows you the XML that has to be changed): .

Note that there is nothing special about "portato" or its musical meaning; any of the MS articulations can be exploited in this way to mean whatever you want, but in so doing, you lose the ability to use them in that score with their MS meaning; for instance, the two Bach scores cited both have "staccato" from the composer. "Portato" is simply the least likely to be used. No matter which articulations you abuse in this way, you might want to hide them in the visible score (the conflict between performance score and reference score comes into play here, as it were).

Add your thoughts
3 months ago

Love “Breaths & Pauses”? So do I, but you can't use them for via-midi performance.

MuseScore's “Breaths and Pauses”, especially after you patch your workspace so that they work, are terrific for inserting those gestures in scores, particularly between lines of hymns, chorales and the like, which, without them, melt into each other.

For better or worse, MuseScore (today) implements “Breaths & Pauses” “non-metrically”: the metronome/clock is just paused for a fifth of a second (or whatever value you edit into your workspace). It usually sounds great; see any of my Bach Chorales. However, because they are “outside of the metronome”, there is no way to represent them in MIDI files, which are deeply committed to metronomes. So when MuseScore outputs a midi file, no trace of the pauses and breaths remain in it.

This has implications for both my earlier postings. If you drive Hauptwerk, Grand Orgue (which, like “Hauptwerk”, is just “Great” in meaning) or any other app or tool via MuseScore-produced MIDI, you'll notice your pauses missing. Worse yet, if you try to merge back with MuseScore-produced .wav or .mp3, your renderings will slowly pull out of sync.

There are two differingly “in-metronome” substitutes I know; neither is pleasant. Number 1 is the awful Piano Roll Editor, to cut back notes which you then might be able to slow down with “active fermatas”. Number 2 is even less appealing (I do this in the Air from BWV 1068) : secretly change measure properties from 4/4 to 17/16, or 9/8, after all the notes have been put in place. This will simply insert a sixteenth or eighth rest which can be hidden and fermata-coerced into a suitable real-time duration. This has the unpleasant side-effect that measures so mangled cannot be copied to empty score (MuseScore still has no way of copying measures of different lengths into empty score not already fit to those lengths, and it doesn't seem in queue for solution).

If you're dealing in solo organ music, my Phraser tool described in an earlier post is a fine solution, but it will not help you cut back the notes of any instrument to be rendered by MuseScore. The same applies to any other MIDI-editing tool you may have, no matter how elaborate. Manual edits do not migrate back to the .mscz, and that's the end of them. That's why my scripted, re-applicable edits are appealing.

Add your thoughts
a year ago

Python tools now supporting Grand Orgue shareware VPO application

I have augmented my free-for-the-asking Python tool-set to support Grand Orgue, as well as Hauptwerk. These tools process MIDI files generated by MuseScore and route staves, insert note-cutback phrasings and manage VPO registrations (including manual changes) according to schedules you provide, so that the VPO applications can perform them. They also detect and ameliorate “unison collisions” (discussed at great length in other posts in this group). A powerful MIDI dumping tool is included as well. With the help of Gertim (who has Grand Orgue) we have support for two of Piotr Grabowski’s shareware soundsets. Included is new documentation, including on how to provide support for new soundsets (Hauptwerk or GO; it's easy).

Add your thoughts
5 months ago

More on note-end collisions (premature shutoffs due to unisons) and VPO's

The problem of note-end collisions, that is, the sooner-ending of two notes at a unison on the same keyboard shutting off the other prematurely, is not limited to MuseScore, or even MIDI instruments; it is an intrinsic problem in the reduction of instrumental or choral scores (or polyphony imitating them) to a keyboard or keyboard-like device (such as a MIDI channel). I have already described and discussed this at length in this group at .

But, while preparing this new score, (video source), using my own software to “smash” (i.e., “reduce”) all the choral parts to performance on one VPO manual, this problem plagued me in a new way that even the most comprehensive, generous fix to MuseScore could not possibly address, as it arises in the reduction process. I write to advise others attempting similar mechanism.

See, for example, measure 21 of that score, second (half-note) beat, where the D half-note in the alto counterpoint ends at the third beat, while the tenor, with the subject, is sounding a whole note on the same note, which should last one more beat. When “sung”, even by the “Chœur MIDI” de MuseScore, this is no problem. But when reduced to a keyboard, with automatic help or not, the D in the alto must not be released at all. If the tenor were on the pedal or other manual coupled mechanically, the alto D would not even be played—the key would already be depressed and held sufficiently long by the coupler.

I have modified my MS->Hauptwerk software (free for the asking) to detect and repair such occurrences, of which 14 are found in this score. The new feature locates (optionally reporting) and removes the “thief” note-off event who “steals” the shutoff from the longer note in each case, whether in the same staff (e.g., continuo realization, where “silence the note in MS” usually (but not always) suffices) or another (but directed to the same manual/channel).

Anyone creating software putatively usable to target multiple MS staves to one VPO (or other synthesizer) manual must do the same.

Add your thoughts
6 months ago

Staves, channels, and tracks in MuseScore

Any attempt to pipe music from MuseScore to another app via MIDI files is going to encounter the issue of how our beloved app maps its native, user-visible concepts into MIDI concepts visible to the next application in the pipeline.

The MuseScore user-visible concepts are “instruments”, “staves”, and “sub-instruments”. I don’t know the precise MuseScore term for the latter, but I’m using the term to denote the three instruments that show up in the Mixer for each string instrument you add, one with with pizzicato, one with a mute (sordino), and one “plain”, the usual one (and always the first in the mixer). When you apply pizzicato or sordino to string notes, these “sub-instruments” are “played”.

In general, woodwind and brass instruments appear in MuseScore scores on one staff, and only one “instrument” plays there. They account for one staff, and one “midi channel”, to which their notes are routed.

String instruments, as discussed (and maybe some others), have “sub-instruments” hiding behind them, pizzicato and muted violinists hiding travelling with the so-called “normal” one, thus being three instruments in but one staff! Res miranda.

On the other side of the ledger are keyboard instruments such as (MuseScore) piano, organ, and harpsichord, which appear there on two or three staves (the so-called “Grand Staff”) on MuseScore, but provide only one instrument for them, and all of whose notes are sent to but one channel, which, as noted years ago, prevents you from changing the “instrument” one on staff of the Grand Staff but not others (e.g., for orchestral adaptation of keyboard repertoire). Two or three staves, one instrument.

Thus, the number of MIDI channels used by a score may be the same, fewer, or more, than the number of staves. Each staff may provide notes to one, several, or (arguably) “fewer than one” MIDI channels. Channels are important because they are “virtual keyboards”, “synthesizer instruments”. What this means is that there is only one “sound quality” per channel (in a given stretch of the piece) and any note on a given channel is either on or off — subsequent requests to play a note that has not been released are ignored, as on a piano or organ, but not adjacent strings of a violin. This has grave consequences and the root cause of one of MuseScore’s most persistent and annoying apparent bugs, “Short notes cut off long ones on same note” (see my later post here about this:

Furthermore, performance platforms such as Hauptwerk and Grand Orgue will define what their channels mean, and expect appropriate input on them.

MIDI files (as opposed to real-time MIDI control of instruments by controllers) comprise an array of “Tracks”, each of which contain their time-sequence of notes (actually, “Note On” and “Note Off”), with timings. The tracks "track" time in parallel. Any track can contain notes for any channel, but in the simplest cases (see above), the mapping is one-to-one. The “intent” in the MIDI design is that of a studio producer, saying “let’s hear this track and not that one.” They are not strictly necessary, for real-time MIDI instrument control doesn’t need them; they are an organizational artifact of MIDI files.

MuseScore associates tracks one-to-one with staves. Each staff, whether it’s for a violin with its two hidden subcontractors, or one of a harpsichord’s three or piano’s two staves, gets ONE TRACK. If the staff and the track are for a violin, there may be note-events or any of three channels in the track. If the staff and the track belong to a harpsichord or piano, only note-events for the right or left hand (or pedal) as chosen will appear in the track.

Thus, if you are designing tools that process MuseScore MIDI, you must decide how you will interpret the track and channel routings that MuseScore produces.

For what it’s worth, my Python tools can be directed to either tracks or channels as the basis for mapping to Hauptwerk channels. In the case of organ music prepared on three non-grand staves, the best way, these are identical. For organ parts in ensemble music, staves are a better choice than channels (because of the proliferation of string “sub-instrument” parts).

Add your thoughts
a year ago

“VPO not” - an AHA! moment about the “MS Church Organ” and its problems (mixtures!)

Responding to a MSian's complaint about a score I borrowed utilizing the sometimes-impressive “Church Organ/Pipe Organ” in MS's soundfount, I came to a tentative explanation about why its notes sound so inconsistent, e.g., the strange octave-sounding discontinuity between A4 and B4 (the A and B above middle C). The problem is that this plenum registration, which sounds terrific in chords, features “mixtures” (look up "organ mixture"), organ stops typical in registrations with the sharp sound of the plenum that you hear there which supplement upper harmonics and balance the sound of different ranges of keyboard, and NOT EVERY NOTE IS SAMPLED IN THE SOUNDFONT (as it is in VPO's). Each note of a "mixture" plays more than one pipe, often three, four, or more, little pipes (a mixture of iii, iv or v etc. "ranks"), that "break back" octaves, i.e., jump an octave lower at carefully selected points different for each rank of the mixture. When the work of a competent builder, playing a keyboard-long scale on such a mixture (alone, exactly what it is not designed for) sounds like "Shepard Tones" (look it up), the scale that somehow never ends, by design, i.e., WITHOUT CLEARLY AUDIBLE DISCONTINUITIES! The problem in MS, I think, is that the design of the sampling scheme, taking a few notes here and there and "stretching" them to be "other notes", runs afoul of the classic "mixture" scheme, gluing together different "ranges" of the mixture, giving rise to glaring, audible discontinuities. When mixtures are in use, a note CANNOT be approximated by playing (say) the note an octave lower at twice the speed! Non-linear organ stops cannot be interpolated/extrapolated by linear scaling.
Another reason why it is a shame that the MS Site/organization does not permit uploading of your own (VPO) soundtracks, but requires commerce with Google/YouTube.

Add your thoughts
8 months ago

Python, MIDI, Status Bytes, and Hauptwerk

This is only of relevance to people using Python to process MIDI files, and extremely technical. If that’s not you, you can skip this.

The python-midi package written and posted by “Vishnu Bob” (a sobriquet) on GitHub has not been updated in 2 years; In that time, many pending updates (“pull requests”) have been submitted that have not been integrated, fixing a number of issues, including one in particular that directly impedes its use with Hauptwerk. I’ll describe the issue below. A GitHub MIDI contributor already has a “branch” in which he has fixed this problem - its “repository” is , which you’d better use instead of Vishnu Bob’s “master”, until, with apologies to Rabindranath Tagore, the latter “wakens from his meditation.” I have my own private fixed versions as well.

MIDI files comprise intermixed sequences of three types of “events”, “General events” such as note-on’s and -off’s, directed to a specific channel, “Meta events” , such as time signatures and textual information not directed to a specific channel, and “System Exclusive events” (“Sysex”) outside the standard and defined by a specific vendor. The standard allows successive “general events” of the same “command” (e.g. “note on”) on the same channel to optimize file length by omitting the “status byte” specifying the command and channel on all but the first (yes, it is possible to encode this deterministically).

The standard says that when a Sysex or Meta event interrupts a stream of General events, this optimization is reset; the first General event after either must carry a status byte. The base (2015) python-midi doesn’t do this, and Hauptwerk gets very upset, diagnosing it (“Bad status byte”) and rejecting the file (in the Sysex case; Sysex is how you control its registration).

If you are programming MIDI in Python and are confused by this, please site-mail me.

Add your thoughts
8 months ago

Note collisions: The “keyboard” model, and an almost-unfixable “MuseScore bug”

MIDI implements what I call a “keyboard model”, that is, instruments are viewed as single, virtual pianos on which you can strike a note (with varying degrees of force), and later release it. There are two corresponding MIDI “events” that are issued in real-time (or packaged time-marked into MIDI files), “Note On” and “Note Off” (although the latter is sometimes, including all the time in MuseScore, represented by “Note On with no ‘force’ (velocity)”). Any given note is either “on” or “off” at any given time.

Why this should be a problem is far from obvious. The (widespread use of counterpoint, or reduction of choral or orchestral music for keyboard — harpsichord, piano, organ (pipe, electronic, or VPO), synth, equivalently — presents a situation where multiple ‘voices’, simultaneous, self-consistent, purposeful musical ‘streams’ of notes (i.e., “melodies”), are required of the single keyboard. While our ten fingers are well-suited to this task, a real problem arises when a “turf conflict” occurs, i.e, one voice is written as striking a note that another is already sounding (a “unison”). In a real orchestra or chorus, this is not a problem — the listener hears both singers or players temporarily singing or playing the same note. On a keyboard, that cannot happen – there is only one key, and one string or pipe, and a the later-arriving voice must “disappear”. And when the sooner-ending voice leaves the disputed turf, the later-ending one must continue.

(Note that this is to be distinguished from “harmony”, where many notes on the keyboard are sounded at the same time. When notes' primary allegiance is to chords, not voices, the notion of “two of them [being] the same” is meaningless.)

When unisons occur, score tools such as MuseScore routinely emit two “Note On”s followed by two “Note Off”s for the same note, unaware of this problem. The second “Note On” is always ignored by the instrument, “the note is already on”, and the first “Note Off” indeed turns the note off, wrongly, and the second is similarly ignored. All MIDI instruments/renderers I have ever used, including Hauptwerk, ignore seemingly-“redundant” commands for the same note on the same channel, as the "keyboard model" demands that they should.

Note that a MIDI keyboard (more accurately, "keyboard-controller") cannot possibly emit two “Note On”s for the same note without an intervening “Note Off”: a physical key MUST be released before it can be struck again! This is not about MIDI keyboard instruments, which behave as do pianos or organs, but about MIDI instruments being “played” by score tools.

Keyboard unisons happen all the time in real music. How a pianist, organist, or harpsichordist deals with them is a matter of style, idiom, and taste. She or he might strike the note again when the later-starting note arrives or not. But when the earlier-leaving note does so, releasing the unison (which is what MuseScore does — see ) is never correct. Re-striking the longer note makes no sense either; only ignoring the earlier release can be justified.

This problem hobbles MuseScore novices unaware of the problem or its work-around: “When two voices in the same staff (viz., routed to the same MIDI channel) coincide, silence the shorter note in the Inspector (uncheck “Play”; you usually have to scroll the Inspector down to see it).". Scores of scores of novices [sic], especially of piano or organ music where this frequently occurs, are rife with sixteenth-notes passing through whole notes, clipping them. As this is really “per channel”, not “per staff”, “Grand Staves” suffer this regularly. Notably, when the MuseScore "Grand Staff" organ is used, low manual flourishes over a sustained pedal invariably clip the latter (if the former's unison strikes are not silenced).

When the colliding notes are not “cleanly nested”, i.e., the later-arriving one is not the earlier-leaving one (see mm.33-34, top two voices, of "Show Invisible" in the View menu.), the work-around fails; both voices must be silenced and a hidden voice or staff called in to help.

For what it's worth, colliding notes that end together, or are wholly coincident (both start and end together), do not damage performance, although redundant MIDI events are still issued and received. For some instruments and idioms, even this isn't right (e.g., the unison D on two strings that opens Bach's D Minor violin partita BWV 1004) – the “keyboard model” does not suit polyphonic string instruments well.

Another consequence of this problem concerns the common use of a single staff to represent multiple orchestral (or choral) parts at once. The most common example of this is the Hymnal usage of two staves for four voices. Another is staff parsimony achieved by putting “Flute 1” and “Flute 2” as two “voices” on the same staff. As long as the voices do not collide, there is no problem — but if they do, not only can a short note clip a long note as just discussed, but another problem arises: as long as the two flutes (or what have you) are in unison, only one flute note is sounded, whereas in a real ensemble, the louder sound of two flutes would be heard. That is, every coincidence of two parts on the same staff in MuseScore provokes an inauthentic volume drop. (Amazingly, this does not happen if, for strings, one is “con sordino” or pizzicato and the other not, for MuseScore assigns them separate MIDI channels.)

This matter is of signal importance to Virtual Pipe Organ enthusiasts, for VPO performances will suffer in the exact same way when unisons occur. VPO implementations do what they are told, as they should, and the “keyboard model” has no provision or protocol for handling unison collisions, nor, I would argue, should it: you must address it in MuseScore. The exact same would befall a MIDI-enabled pipe organ (as many new electric-action ones are).

Note that when two or more staves, no matter how meticulously separated as “non-grand”, i.e., sounding different channels, by fastidious MuseScore use, are routed to the same VPO manual during a given stretch of score (exceedingly common), unisons between the two staves will suffer this problem on that manual, even if performance in MuseScore will not! (My tools do not currently detect this case, although they can be asked (via control argument) to detect and flag unisons in one staff).

(Interesting note: when real pipe organs, or virtual ones, even historic ones with tracker action, are played with a pedal coupler, and playing on the coupled manual collides with a held pedal note, playing the manual note has no effect—on tracker instruments, it will already be depressed! Thus, there is no option to “re-strike” the manual note as discussed above. If the pedal is not coupled to the manual, they are effectively different instruments. On the MuseScore Grand Staff, they are always the same instrument and there is no such beast as a “coupler”.)

More discussion and ideas at

Add your thoughts
a year ago

Hauptwerk only: The waywardness of General Cancel

This is Hauptwerk-specific. I’m not even sure this discovery is important enough to post about, but it is certainly curious and worth knowing about, and if anyone reading this has better info, I'm eager to hear it.

If you start “MIDI recording” Hauptwerk by clicking the appropriate control before performing/improvising, it might take you a few seconds before you seat yourself at whatever you have that imitates an organ and start playing. And good thing, too — at least six seconds, or else… If you have an assistant, show that assistant how to start a MIDI recording, and try to start playing before he or she clicks “start”.

You may have already noticed that when you click “start MIDI recording”, all stops you have drawn are cancelled — the knobs retract -- presumably, that is to force you to set your registrations and get them recorded on the MIDI recording. But if your assistant immediately sets a registration to restore your rudely interrupted playing, for the next several seconds, as soon as they come on, the "pipes" “wheeze and stutter” as though the blower is having problems!

Now, of course, you will never suffer this unless you start a MIDI recording, set up your registrations, and start playing all within six seconds. But you just might. Just saying (at least this is true with Sonus Paradisi Doesburg)!

I am posting this because the function of cancelling all stops, “General Cancel”, is a very useful one, which I would like to have at the start of all my MIDI tracks for Hauptwerk, such as those produced (originally) with MuseScore. So I inspected a MIDI file made by Hauptwerk to find what it puts there to accomplish this, and found a “System Exclusive” command event with data [11, 125, 57, 114, 28, 0, 0, 10, 27, 4, 1]. When I attempted to inject the same into my files, it badly mangled whatever notes were played during the next six seconds! It seems to be a “general knockout” that affects the simulated blowers, “or something”. If I fabricate a bogus measure 6 seconds long, it “works”, wasting that much time on playback.

I have not been able to make the ControlChange events generated by the “General Cancel” button work in my own MIDI files, although I can make other global controls (e.g., "Master" couplers such as "I to I 4' ") work effortlessly.

If anyone has relevant knowledge, please share! Thanks!

Add your thoughts
a year ago

Locating "Start of Piece", versus "Start of Sound", and "rests at the beginning."

In earlier posts, I advise the use of Audacity or other audio editors to visually locate the start of VPO (virtual pipe organ) recordings to line them up with MuseScore. There are two reasons to do so: (1) to post VPO-created sound as the audio source for an online MuseScore (2) to combine VPO-created sound with MuseScore-realized sound as explained in, to audio-source a score. I advise that the VPO track “had better start at the beginning of the piece”, i.e., commence immediately, for this to work.

But what if not? Occasionally, works begin in mid-measure, with fully-notated rests preceding the first note, especially in fugues. In this case, the MuseScore performance will, and VPO and other offline performances must as well; the amount of silent time must be precisely correct if parts are to combine, or even the MuseScore measure-cursor is to progress at the correct times.

Opening rests, are, of course, represented (in a manner of speaking) in MIDI files, and if you play the MIDI file (appropriately transmogrified), the resultant silence will “appear” in the output recording, although the performance's start will not be distinguishable from the lead-in silence between the start of audio recording and the start of playback (simulated stop-action noise scheduled for the start of the piece notwithstanding!).

Finding the “start of playback” backwards from the visible “start of sound” is conceptually simple. Assuming there are no tempo changes during the initial silence (!!), you can calculate its real-time length from the musical length of the rest (e.g., “three eighths (i.e., eighth-notes))” and the tempo (e.g., “70 quarters per minute”). Then you can locate it exactly in Audacity by finding the “start of sound” visually and going back that much (Audacity allows you to specify a time location numerically) and cut everything before that.

Another way is to insert a short bogus note at the start of the performance, perform and record the piece with it, and then erase it from the score and the recording, although its acoustic venue echoes may render the latter difficult.

In any case, the calculation is complicated by two small contributions, the “attack delay” of the instrument, i.e., how long after being “told to play” sound starts, and a seemingly constant MuseScore attack delay. The “attack delay” varies from instrument to instrument, and depends not only on that, but the lineup of the “start of sound” in MuseScore’s samples (or Hauptwerk’s). I’ll get back to this momentarily.

The “MuseScore attack delay” can be observed by creating a one-note score for a MuseScore electronic instrument such as “square (wave) generator”, and export to sound, and study the .wav or .mp3 file - you will find that the start of sound follows the start of the recording by .052 (about 1/20) second. If you use the “Church Organ”, you will see a .058 second delay — that .006 sec difference can be written off as the “attack delay” of that instrument.

One or both attack delays can be ignored if you are satisfied with the results of doing so.

Thus, when you create a MuseScore-backable MP3 from a VPO recording, you should leave .05 seconds, plus whatever the true duration of the opening rests are, before the visible start of sound.

Example: quarter=70, 3/8 delay. (60/70) = 0.857 sec/quarter note, that*4 = 3.428 sec/whole, that*(3/8) = 1.2885 musical delay, that + .05 sec MuseScore attack delay = 1.34 sec needed delay. Visual inspection reveals that sound starts at 4.04 sec in a recent recording, so 4.04-1.34 = 2.70 seconds need be deleted from the front.

You can check your work here by enabling the native MuseScore organ (or whatever you assign to the tracks you will use for the VPO), making a .wav from MuseScore, reading it into Audacity, and import (into the same project) the VPO output. Assuming A440 for the VPO, you can play them simultaneously and it should sound like one organ when the VPO output is aligned properly. You will probably have to up the VPO tracks by 10 or 15dB to do this. When cooked, close the raw MuseScore track (of the two) and export the project to MP3.

Add your thoughts
a year ago

Detailed recipe of how I achieved “Lauda Anima”

A friend of mine, admiring my Lauda Anima (“Praise, my soul, the King of Heaven”,, asked for detail on how I achieved such a thing, and I replied at length. Another friend suggested that I post that response here, so, with appropriate edits, ... (a lot of material covered in recent posts is duplicated) ...

Prerequisite and motivating was to know and love this gorgeous English hymn, which I have heard countless times in numerous churches, and admire its grand “High Church” atmospherics. A couple of weeks ago, I was improvising on it at my new “organ-like device” (i.e., collection of computers, software, keyboards, pedals, and loudspeakers) and realized that I couldn’t reconstruct the approach to the heart-gripping 13th chord after the second Alleluia with 100% accuracy, so I decided to look for a score on the internet.

I landed upon which says it comes from the Pilgrim Hymnal, but no composer of the arrangement (other than the composer of the tune, John Goss (1800-1880), student of Mozart student Thomas Attwood and teacher of John Stainer) is listed, and Public Domain is mentioned. It reveals a two-staff accompaniment, presumably but not unambiguously organ, and vocal parts in both unison and 4-part harmony (at which point the accompaniment simply doubles those parts). It matched my church memory of its harmonies: interestingly, the four verses employ different, wonderful, harmonies, and treat the “magic chord” in measure 22 in different ways. I have detailed and analyzed these differences here: . At that time, I decided to “type it in” and “publish” it via MuseScore. The organ intro and break and the descant I composed in the subsequent days — I’ll get to them soon.

I made some decisions about performance: I gave verses 1 and 4, which show single-line vocal parts, to choral unison in all parts. Verse 2 appears in the score in choral harmony, so that choice was clear. I gave verse 3, which is also provided with a solo line, to “soprano and alto” unison. I use quotes because the voice-qualities are indistinguishable in synthesized performance (and anyway, women, or any people, who sing don’t partition into “four discrete classes”).

So I sought to enter the score into the MuseScore application, (you all know this, but) a general-purpose, open-source, free score preparation and editing tool that I have been using for the past three years and some. It is available at . It runs on Windows, Mac, or Linux, and is easy to use, and includes significant synthesis/performance abilities. I recommend it highly (it is not as capable as its expensive peers, Sibelius and Finale, but it is excellent!) Its “choir”, i.e., its choral voices, is the ones you hear, but not its “one registration only” organ.

I entered the score exactly as in my “might be Goss” PDF, four voices and organ, putting the latter on the usual three staves instead of two, and using the pedal only in the first and final verses for drama. For the first draft, I indeed used the one “Church Organ” (among 128 “world instruments” of “General MIDI”) sound that MuseScore provides. I added traditional “dynamic markings” to quiet the silly “church organ” (which boasts (only) a loud plenum registration) during the second and third verses. This part was fairly easy.

Next, I employed tools in MuseScore (a messy facility called the “Piano Roll Editor”, which presents an interface looking like its namesake) to insert “phrasing breaks”/breaths between lines of the hymn, including “alleluias”, cutting back the vocal lines by tiny fractions of a second between hymn lines, in all voices (and even sometimes organ). Without these “cutbacks”, they run into each other, and it sounds unnatural and electronic. You don’t realize it when you listen, because it sounds natural. You’d realize it if I hadn’t taken this care. (Cognoscenti: Even though a hymn is the ideal case, I knew I could not use MuseScore “breaths”: see

At this point, I could have “published” the score on (the voluntary community of happy users of MuseScore). It is run by the same people, in Europe and here. The site will accept scores created with MuseScore, which you can upload, and thus, “publish”, under your own account, and are visible and playable to the outside world. That’s what you see.

Had I published it as is, it would have used the MuseScore “General MIDI” “church organ”, the single plenum sound available under that name in the app. For the first and fourth verses, that was actually pretty reasonable, but nowhere as good as what you hear now.

At this point, I thought about improving the presentation by using the beautiful real-organ sounds, carefully registered, provided by my Hauptwerk Virtual Pipe Organ (VPO) system. I would experiment to see if it would work. Happily, Hauptwerk allows one to “re-tune” organs quickly—something of a miracle. The instrument I proposed to use was built with A = 433.1, and I would need, and set, A=440 to play along with MuseScore voices.

MuseScore, the web site, also allows you to supply some other “sound track” for your score than its own synthesis; that currently must be supplied by a YouTube video, but I hear that very soon it will allow sound (MP3) files directly, a very great convenience. When the MuseScore site uses an “alternate audio source” in this fashion, it plays it while moving the pink “measure cursor” along the score at the exact correct times computed from the score you uploaded. If you don’t provide an “alternate audio source”, the site runs the app “behind the scenes” at the time you upload to create a “sound file” (MP3), which it similarly “plays” while tracking the score when a visitor presses “play”.

So I chose to provide such an “alternate sound source” from my Hauptwerk system, which not only sounds a lot better than the MuseScore's single-registration “Church Organ”, but offers thousands of possible registrations, instead of just one!

Next I needed some musical work. I sat down at the three “keyboards” (serving as “manuals”) and pedals of my “VPO system”, and played the verses of the hymn with my hands and feet, on the VPO image of the Walcker organ at Doesburg, Holland, to decide on appropriate registrations, and write them down. I had to iterate this over the course of the project, being dissatisfied at times with the result, and taking the advice of another organist for one of my choices—architecting the organ sound so that the first verse is grand, but not as grand as the climactic fourth verse, while the inner verses were less grand but still reverent, was the design goal.

Once I had arrived at what I thought were workable registrations, I wrote them down in a file in a private text format called a “registration schedule”, which is the input to a new program called the “Registrator”, which I have written, which specializes in processing files written by MuseScore so that Hauptwerk can “play” them. This is necessary because, in spite of the standard music digital format (MIDI) that both apps support, they have differing notions for the assignment of “channels”; furthermore, the music editor has no facilities for generating the codes that are necessary to control registrations on Hauptwerk, nor to tell Hauptwerk which staves of the score to play, and on what manuals or pedals. I have written more about these programs and the need for them at . There is an example there of a registration schedule.

With that out of the way, I asked MuseScore to create ("export to") a “MIDI” file. “MIDI” stands for “Musical Instrument Digital Interface”, and provides a communications protocol of “events” which electronic musical instruments have been sending to each other for decades. It also defines a kind of file, a “MIDI” file, which is a schedule of such events, packed by “track”, and marked by the time each is supposed to be played. Typical events are “note on” and “note off”, which include pitch and channel, but special events only understood by the certain instruments or programs are allowed, too (“System Exclusive” events). Hauptwerk can “play” from MIDI files, like a “piano roll”, and obey such “System Exclusive” events scripted to assert and change its registrations.

I then took the MIDI file produced by MuseScore, and ran it through my “Registrator” program, which simultaneously read my “registration schedule” and my similar definition of the Doesburg organ (detailing what its stop and manual names mean in terms of the “System Exclusive” commands that have to be generated to tell Hauptwerk how to manipulate them), and produced a new “MIDI file”, which I transferred from my MacBook laptop to the mighty computer I use to implement Hauptwerk (via a very magical USB-to-USB cable!).

Then, seated before the touch-screen of the Hauptwerk “organ”, I asked it to “load” (i.e., prepare to “play”) that MIDI file, with the my amplifier on so I could hear the result. Before I pressed “play”, though, I pressed “record to .wav file”, then, a second or so later, “Play MIDI file”. Hauptwerk produces sound by combining pipe images and feeding the result to the computer’s sound card. It can be asked to make a “.wav” (wave) file at the same time, which is very inexpensive (in computer resources): it just accumulates the sound values it sends to the sound card. The resulting files are always large, about ten times the size of MP3 files, which latter are ingeniously compressed, for the same length of performance.

When this was done, I hit “stop recording”, and assigned a name to the .wav file. Actually, I had to iterate these steps (starting with “create/edit the registration schedule”) several times until I was satisfied with the performance. “Actually actually”, sometimes I pressed the “stop knobs” on the touch screen as the MIDI file was playing — while this ruined the recording (trivial to re-make), it allowed me to experiment with finding the best registrations. This is a particular joy of VPO’s!

With a good wave-file on my Hauptwerk computer, I used my UGREEN double-usb-magic cable to get it back on the Mac, where, of course, I listened to it immediately.

Now in order to facilitate combination with the choral sound, it is necessary to ensure that the organ starts at exactly the beginning of the score, or the two performances will not “line up!” I detail the next steps here,, but I’ll outline them for you.

I used the Audacity audio editor to “shave” the beginning of the Hauptwerk-produced wave file, to eliminate the short time between when I pressed “record” and “Play MIDI file”, so that in my final result, not only do the two performances line up with each other, but that they line up with the score’s measures when played back online, as previously discussed.

Next, I had to produce a second .wav file, of only the choral voices. That is easy; I asked MuseScore to “mute” the “church organ” parts in my score, and “export to wave file”, which it did, in a short time — it did not have to “play” the score “in real time”, as did Hauptwerk. Wave files made by MuseScore are always exactly “lined up” with the score which produced them, even if they start with silent measures! The resulting wave file had NO organ of any kind, just choral voices.

With the second .wav file available, I used Audacity to read them into one “Audacity Project”, where I could “master” a recording of the pair mixed. The timings line up by design. I had to balance them carefully to taste, such that the organ was grand and majestic but not overpowering the chorus. With this done, I exported the result as MP3.

Unfortunately, at this point I needed a YouTube — this will change soon, I am promised. Because I do not want to be part of the Google, Inc. ecology/economy, so I avoid having a YouTube account, I relied on the kind services of a friend to post one for me. There is a site,, which takes sound files (MP3) and creates YouTubes (you still need a YouTube account) of nothing more than that, with an image you provide. The YouTube will then have the exact timing characteristics of the MP3 from which i was created.

So I sent my friend the MP3 File from Audacity, and he used that site and his YouTube account to make a YouTube, and sent me its URL. I then uploaded my score (with all parts enabled, including the inadequate “Church Organ”) to, where I have well over a hundred scores from the past 3 years, and a following of 200 or so, as well as public visibility.

I then had to tell MuseScore (.com) “Please use the YouTube video whose URL I am giving you as the default sound source for this score”. Which it did, and so arrived at my first goal.

Encouraged by my various friends’ responses, I decided that an organ “intro” was necessary. First step was to sit down at the VPO organ and improvise one, and, hopefully, try several times and remember the best ideas. So I did — copying/modifying the closing “alleluias” and the “best cadence chords” of the arrangement was formulaic, but effective.

I went back to the MuseScore editor, and “composed” the opening organ intro, opening up ten measures at the beginning of the score to do so, and listening on the “Church Organ”.

When satisfied, I did all the steps, from “produce/edit registration schedule” on, over again — they take minutes, not hours. Note that I had to re-record the choral parts, because the 10 measures of organ intro require exactly 10 measures of choral silence to be “recorded” and mixed! And my friend had to make me a new YouTube from the resulting new MP3, reaching my second goal.

Then I decided to compose a descant. There are some issues in my descant — it sounds more like a Bach-like contrapuntal line than the blocky, in-rhythm quarter-note descants in the Episcopal hymnal, but I haven’t yet met anyone who doesn’t like it. The contrapuntal rules of what is acceptable though, are a bit more liberal than Bach’s. To add the descant, I had to add another staff to the MuseScore score, and compose and “debug” one, and crank up its volume.

It was, of course, then necessary to re-record the choral parts, but not the organ part, which did not change, and so I did. However, the added, amped-up descant in the fourth verse changed the ensemble balance changes significantly in the fourth verse, and I DID develop new registrations to achieve credible balance and grandeur, and had to re-record the organ until I could balance them to taste. And so I did, made a new MP3, sent it to my friend for YouTubeization, clued in on that YouTube, and I reached my third goal!

Then, of course, I needed an “organ break” (a rock term; “interlude” is better here). Of course, that required reiteration of all of these technical steps, including re-recording both organ, to include the new material, and the choral parts, to open the corresponding silence for it, and new MP3, YouTube, re-upload of the score, etc., all trivial except the YouTube, so I won’t talk much more about it.

But I will say that developing the actual composition of the organ break was nontrivial, because I do not have as much faith in myself as a composer with pen (or score editor) as an improvising organist. So I sat down at the VPO “console”, and turned on “make .wav file”, but instead of playing a MIDI file, I played the manuals and pedals, and it recorded (at great expanse) what I did. I improvised organ breaks three or four times. Stopping the recording, I brought it back to the Mac, listened to them for the best ideas, and “composed” a good organ break following what I learned from the recordings of my own improvisation, perfecting the detailed counterpoint as well as the overall design (the key design desideratum is coherence with both the end of the last verse and beginning of the next, including ending with recognizable quotation of the final measures of the hymn.) Again, some reiteration was necessary for the registration, including that of other parts of the setting, to present the needed contrasts, drama, and balances, including recording-destroying “fiddling” (better, “organizing”?) during MIDI playback. When this was done, including rewrite of the registration schedule (including its measure numbers!), I had what you hear now.

Add your thoughts
a year ago

The 'violin' instrument of the standard 'soundfont' is out of tune..

This post is related to this organ score, where the violin has a solo role and a Hauptwerk organ supporting it: I corrected the pitch of the high notes in this score!
The violin instrument as part of the standard FluidR3Mono_GM.sf3 Soundfont has a problem. When used as a solo instrument it draws very much attention for being out of tune at higher notes (together with other instruments and depending on the piece it is not that noticeable). Not all notes have this problem to the same extend, but some do. Also the movements of the notes seems to make a huge difference. When going up to a high note it is much more out of pitch than when going down. The note starts too low and then when a note is hold on longer it is also climbing up in pitch. They may have recorded wrong on some notes, or they played it wrong (.wav) when making it part of the Soundfont. So those notes had to be corrected, but the problem is that the pitch also varies. So I had to take an average pitch, which sounded far more acceptable than what comes out as standard sound. So especially the high notes I raised in pitch, because otherwise it really sounded terribly out of tune. The shorter notes (out of tune) don't suffer as much from this climbing up, so they relatively could be corrected better/higher. This is done by selecting a note and then F8. Next raising the tuning of the note. For example (not all the corrections):
violin 1 execution:
measure: note tuning
1.1: -8.3
2.2: 19.6 (the higher notes need more correction)
3.1: 10.20 (starting a bit too lot but taking into accounting the climbing up)
3.2, 16th A: 15.00
measure 3 E 16th: 2.00
last A of measure 3 16th note: 15.00
5 A, 16th note: 15.00
7 A: 1:00
I tried an other soundfont (HQ Orchestral Soundfont Collection V2.0.sf2) and the problem was less, but still there. So, I don't know how this soundfonts was made (based on the same maybe and changed a bit?) However it does make a difference. The correcting of the pitch I made is based on the standard soundfont and does not apply to an other one.
This score has the corrections in them. It has to be played with Violin 1 (top part) silenced/muted in the mixer (F 10). If you want to try an other soundfont, you have to backup the score first and then select all the notes in 'Violin 1 Execution' and remove the tuning corrections. Then go from there (and always mute violin1; corrected on a couple of notes, but by far not all; so that would otherwise influence the pitch too..)

Add your thoughts
a year ago

Organ model vs General MIDI model and MuseScore limitations

The largest problem keeping MuseScore on its own from even vaguely adequate renderings of organ music is not the lack of organ soundfonts (reasonable ones exist—web search for “organ soundfont”). The problem is the contrasting models of ensemble presented by MIDI-compatible synthesis platforms and pipe-organs. I hope I will not offend other organists here by identifying traditional pipe organs as an early general-purpose synthesis platform with its own sound-synthesis model/paradigm.

The number of “sounds” (i.e., sound-qualities) a given division (manual or pedal) of a traditional organ can produce, including silence, is two to the power of the number of stops: any can be on or off ("drawn" or "retired"). Thus, a small organ division of ten stops can offer 1,024 (two to the tenth) sounds. Sixteen can offer sixty-six thousand. A MIDI-based synthesizer can offer exactly 128, the 128 of whatever sound font is loaded (or silence -- "For 25 cents, I won't play at all!" –Marx). Organs compose sounds by combination; MIDI synthesizers do not compose sounds, but rather, select them.

The “General MIDI” font used by default by MuseScore (and if you want to use another one, you can’t post your work for others to play (except via MP3/YouTube), has only one “Church Organ” amidst its zither, sitar, bass trombone, and alien sounds. This is not unreasonable or a disappointment — that’s what they “General” in “General MIDI” means (not an officer from Southern France, as my friend jokes). And, sure enough, it is a “full, plenum” sound, which actually is appropriate for a large amount of organ music, but surely not even slightly all. Unlike “oboe” or even “piano”, “organ” is not a sound but a competing synthesis paradigm.

MuseScore neophytes attempting to write organ music without exception use this single sound and say, "well, yeah, that sounds like an organ, but is not exactly what I had in mind", prompting organists such as Clarin and myself to develop techniques for approximating the variety of organ sound with pan flutes, recorders, and other "tools of destruction" available in MuseScore General Midi.

Now MuseScore, although limited by MIDI in some ways, is not a MIDI synth, but a score-preparation program. You can set up sixteen, or thirty, staves, put all different kinds of instruments on them, if that number is less than 128, and turn them on or off at will. In fact, you have many more sounds than a division of small pipe organ, although their variety, not their musical compatibility ranks high among their virtues. You can have the Pan Flute, Rain Synthesizer, and Snare drums among your “stops”, and combine them in any way you wish.

But if you do so, you must provide a staff for each separate instrument. While that hardly seems a problem for one building ensemble music for diverse instruments, it becomes a terrible pain when you work with more traditional music and want something as simple as “Flute I and Oboe I play along (“colla parte”) with Violin 1”. You need three staves, have to copy and paste and maybe hide staves, and make all changes three times, or more — real composers use ONE staff in this case, and say “Flauto I, Oboe I, Violin I” at its head.

MuseScore can’t do that, and it is a great annoyance. I have asked for such a feature many times, to no avail. It would tremendously simplify the preparation, editing, and even reading of traditional orchestral music of all eras.

In fact, that is precisely an organ-like paradigm, choosing “which instruments [plural!] play a part”, and some composers who were also organists have been accused of using the orchestra “as if it were an organ”.

If MuseScore had such a feature (maybe other score tools do), you could use one of the aforementioned organ soundfonts and easily combine its registers, as long as they were fewer than 128 (that would include the vast majority of real pipe organs, all except the largest). (However, simply to transcend these limitations, most sounds in these soundfonts are pre-cooked combinations, not individual stops. I have not checked them out at length).

Virtual pipe organs do not put individual stops on separate channels — midi channels are scarce. Hauptwerk, at least, puts one manual (or pedal keyboard) on a channel, total a single digits, and asks you to select or cancel such stops as you want. At any rate, interfacing of MuseScore to such platforms involves reconciliation of the two ensemble/synthesis models just discussed.

Add your thoughts
a year ago

Combining Hauptwerk (or other) output with MuseScore instruments

As you can see and hear here, I’ve combined MuseScore voices and instruments (the latter beset by intonation problems, as Gertim discusses) with Hauptwerk output. Other than the production of the latter, combining them involves a few tricks as well as traps you have to avoid.

Musicians who play together have to follow the same conductor and agree on the same pitch. Everything devolves from that.

To accomplish this, compose your score with organ (or whatever) and other instruments or voices. Things will be much, much simpler if the organ starts playing at the very beginning of the score. If this is not so, add a bogus note to make this so, and edit it out later. See also my following post about Breaths and Pauses, which you may not use.

Then agree on a pitch. I recommend modern concert pitch, A=440 (easiest way not to get confused). Many of the classic instruments available for VPO use are tuned to other, historical pitch standards or non-standards. Hauptwerk, at least, will tune any of its organs to A=440 if you ask (there is a “Tuning” menu item).Then produce the organ recording, most easily as .wav (which Hauptwerk, at least, outputs naturally). Reducing to MP3 will take time and lose some quality.

It's also possible that MuseScore, which endeavors to be equal-tempered, might disagree with a historical temperament of an imaged organ or other historical instrument. Hauptwerk will actually re-temper its organs in real time if asked. Temperament can be a pretty big issue ... enough said.

Some scores on MuseScore are deliberately detuned by their authors to historical pitches. If you started with one, or did this yourself, make sure that this is no longer the case, in View | Synthesizer | Master Tuning — Load from Score if you suspect it, change A to 440, and Save To Score. IF YOU NEGLECT TO SAVE TO SCORE, YOUR OUTPUT FILE WILL BE AT THE WRONG PITCH! This is non-obvious, because live playback will NOT be at the wrong pitch in this state.

Then take your MuseScore score, and mute the organ, leaving only the parts which are to play along with the organ, listen to it to make sure it makes sense (and retune your violins if necessary), and “Export” to “Wave Audio (.wav)”.

Now un-mute the MuseScore channels you muted, and save out your .mscz without the mutings.

To combine these, which should now be possible if you have taken the above precautions, you will need an audio editor. Audacity runs on Windows, Mac, and Linux, although there are issues with MacOS Sierra. See for free downloads and info about the Sierra problem. If you intend to make MP3’s, you will have to visit a fairly obscure third-party site to obtain the “LAME” MP3 encoder, as directed there.

These instructions are for Audacity. Open the .wav file produced by the organ performance. Then edit away, by looking at the graphic representation, all the silence between the start of the recording and the start of the organ sound, which will be exactly at the right place if you followed my directions. You can mark it with the mouse-equivalent, and “ctrl-X” (cut) it, but if you have never used an audio editor, you should gain some facility first.

Now you must read the MuseScore output .wav into the same window. Click on a place on it OUTSIDE the audio graph. Choose “File | Import” and “import” the MuseScore output .wav; if you followed my instructions, they will line up perfectly,
If you try to play what you have with its two pairs of tracks, you will probably find that the MuseScore output overwhelms the organ output. I have had to boost the organ output between 8 and 15dB when doing this — audacity offers a little slider to the left of each pair of audio graphs for exactly this purpose. And I have had to attenuate the MuseScore track a few dB, too. You may have to experiment with this to get the balance you want without overflowing “into the red” on the VU (volume unit) bars on top.

When all this is done, Export, to MP3 (assuming you have installed LAME properly). You may or may not want to “save the .aup audio project)”, especially if you keep the .wav files, because you can always recreate it. Assuming that your VPO continues to work, you can always recreate the whole thing.

Getting the MP3 into is a whole other discussion. Right now, it requires posting a YouTube ( will make such a YouTube for you). But you do need a YouTube account to post it, or a willing collaborator with one. I won’t cover this part of it from this point, because it is covered completely here:

Add your thoughts
a year ago

Hauptwerk and MuseScore -- basics and my available Python Programs

Hauptwerk (the only VPO app I have, so I can’t discuss Grand Orgue) and MuseScore don’t know about or talk to each other. There is a defined protocol, VST, by which music apps can talk to and drive each other—Hauptwerk and Sibelius support it, but not MuseScore. MuseScore, however, can output MIDI files, which, when appropriately processed, can be "loaded" and played by Hauptwerk. Hauptwerk will both output MIDI files (as a “piano roll” transcript of playing) and read them back to play. Therefore, it can play any MIDI file carefully engineered to resemble those it writes. Such files must include all the Hauptwerk-specific controls, such as registration and expression control, that are needed.

I have pursued the latter path, and achieved significant success, as you can hear in my files posted here (how to get the output posted and coordinated, especially when you want to combine a Virtual Pipe Organ with MuseScore voices or instruments, is a different problem on which I hope to post soon.)

To do this, I have written a suite of custom “command-line” MIDI-processing programs and substrate. You don’t have to do that, because you can use the software that I have already written. (I have no means for distributing it yet other than email/file sharing). The programs do change as I develop, though, hopefully for the better.

The key program, the “Registrator”, reads the MIDI file produced by MuseScore's “Export (to standard MIDI file)” command, along with descriptions of Hauptwerk organs in a simple text format of my design (".orgdef"), and user-supplied “schedules” of registration settings and changes, keyed by measure and beat number, producing a new MIDI file suitable for Hauptwerk's consumption. The Registrator interprets the registration schedule in reference to the "orgdef", and inserts (into the MIDI tracks) Hauptwerk-specific MIDI commands to effect those registrations and changes. The Registrator also reroutes the staves and channels to the channels representing the desired manual (or pedal) of the Hauptwerk organ in use, changing channel numbers in the notes in the file. While MuseScore assigns channels from 0 by staff from the top of the page (more exactly, "Mixer" rows from the top down), Hauptwerk assigns them to divisions from the floor up, i.e., pedal is 0, then the manuals, from bottom to top. Orgdef and registration schedule samples are pointed to by the first two responses to this post.

Another of these programs, the “Phraser”, also processes MIDI content according to a schedule (it can be invoked within the registration schedule), snipping “cutbacks” off the ends of specified notes, one or more staves at a time as asked; this exists simply because phrasing is so cumbersome in MuseScore; the Piano Roll Editor (PRE), which crashes almost all the time on the Mac, is slow, error-prone, feedback-free, and profoundly non-obvious. A text-based schedule of measure and beat numbers has proven far more convenient than PRE finesse that cannot be seen in the score.

I have also built a measure- and time-signature-aware MIDI dumper (i.e., reports measure and beat position of events) within this tool suite.

So if you want to experiment with these programs, I’ll share them, although I don’t know how much support I can offer. They are written in the Python programming language; experience with the same is NOT necessary, although it might facilitate the installation of the two “external” packages, the “PyYAML” (Yet Another Markup Language, from and “Vishnu Bob’s PyMidi” (on GitHub) you'll need (and on Windows, at least, you have to install Python itself, from

So that’s how I get the results I do. Listen to the Franck Chorales posted here to see and hear extensive use of scripted registration and phrasing management producing an artistically satisfying result.

You can contact me via site mail on (must be a registered user, which is free for small use).

Add your thoughts
a year ago