Gorgeous, but way too much work
I’ve just completed my latest project, which turned out to be
insanely time-consuming, though I can’t quibble with the results.
It’s an arrangement of a song, Inchoate Misery, for an unusual
ensemble: string quartet supplemented by double bass, two harps, two
flugelhorns, two trombones, and a clarinet. The video and midi of
the score are at http://youtu.be/w_Bt2fkGQUE. Well worth checking out.
There were two reasons for the ridiculous amount of time I spent on
this. The first was getting the arpeggiated harp chords to sound
right, and the second was my favourite bugbear, the Note Properties
dialogue, to which I now add the Tempo Properties dialogue.
The problem with harp arpeggiation is that Musescore interprets
the broken chord marking as meaning “start on the beat” and “arpeggiate by
32nds” (or 64ths, it's hard to tell). This is rarely how chords are
broken. They often (usually?) begin slightly before the beat,
and are performed much quicker than, say, 32nds or 64ths at a tempo
of quarter = mm75, which was my prevailing tempo. Getting my harp
chords to sound right took hours and hours of fussy, repetitive
work. Avoiding fussy, repetitive work is what computers are for,
so I was dismayed by having to do it.
I won’t get into how I overcame the problem, though if anyone’s
interested, ask. Suffice it to say that a feature I would really
like to see in 2.0 (I’m still with 1.3; no nightly build has been
stable enough for me to use) are “fast” and “slow” options as a
Property of the broken chord marking. “On the beat” and “before the
beat” would be terrific, too.
On the subject of harps, I cannot get the harp pedal plugin to work.
Someone else had a similar problem and found it was a question of
getting Harpfont.ttf in the right directory. They neglected
to say which directory, though. I’ve got Harpfont.ttf in
/usr/share/fonts/truetype, /usr/local/share/fonts/truetype, and
~/.fonts/. Apparently, none of these is correct. Help appreciated.
Along with manually tweaking every single harp chord, I once again
found myself tussling with the Note Properties dialogue, having
to reset hundreds of note properties one by one because of the
Note Properties’ mishandling of batch changes. Simply put, it is
essential that if one selects several notes with a similar velocity
but differing offsets, then changes the velocity (say, for reasons
of balance), ONLY the velocity of the selected notes should change;
the offsets must not be touched. Please tell me this will be fixed
in the mythical-seeming 2.0 release.
There are a huge number of hidden tempo markings in the Inchoate
score (largely related to the broken chord problem), and I wasted a
lot of time with them because the Tempo Properties dialogue doesn’t
update the text associated with the tempo. While that’s fine if the
text is descriptive (Adagio, Moderato, etc), when it's numeric it
means right clicking on the original tempo text (eg 75), selecting
Tempo Properties, changing the value (eg to 72), then double clicking on
the text and replacing it with new text. Try doing that a couple of
hundred times, and it becomes apparent that once again, the computer
isn’t doing the work, you are. So we need an option to go along
with Tempo Properties, “Update tempo text” or something similar.
Lastly, group selecting and moving of staff text that has associated
“lines” (eg rit._ _ _ _ _) results in the lines going to weirdly
random locations, so everything has to be lined up horizontally
again. Wow, is that an eye-killer. Another eye-killer I’d like to
see fixed is the zoom. First, I want to be able to enter my own
zoom percentage, not be locked in by Musescore's pre-chosen
increments. Secondly, when I zoom to a particular spot near
the bottom of a score, I absolutely do not want the score to jump
off that spot to the top of the page when playback starts.
Mightily annoying.
Musescore produces excellent results. My YouTube channel exists
largely to show off what it can do and to encourage more widespread
use. If I seem a tad critical in this post, it is of details related to workflow,
not of the software itself.
Comments
I'm sure you've heard me or other mention this before, but the main focus of MuseScore remains the notation, not the playback. So if getting the notation right was not the issue, I'd say that's probably as much as can be reasonably hoped for now.
BTW, 2.0 will feature option to for tempo text to automatically follow text. It's possibly the new articulation editor will also make the work of getting playback of harp arpeggios to sound as you prefer.
In reply to I'm sure you've heard me or by Marc Sabatella
I recognize and acknowledge Musescore’s notation mandate. And as an open-source developer (the “mom” macros for GNU/Linux groff), I know the frustration of creating something that’s “almost perfect” for a particular user’s needs, only to have to tell them that your focus for the program doesn’t permit allocating resources and time to that final bit of development they’re hoping you’ll implement.
It was never my intention, when I started with Musescore, to use it for anything other than engraving scores. Then I discovered its playback capabilities and began, quite reasonably, to incorporate both notation and playback into my thinking while creating scores. The possibility of engraving directly (as opposed to composing with pencil in hand and re-doing all the work later for a final fair copy) was already a great assist, but when the possibility of decent audio prototyping was added to the mix, it was like being handed the keys to the candy factory. What could be more perfect than a programme that not only generates beautiful scores but also lets you realize the music from the score itself? I can’t begin to say what a fantastic inspiration that has been to me. It stimulates me to write more, to experiment, to try out new ideas, to test things I’d never be able to try out in real life.
In short, if I seem to harping on playback issues, the Musescore developers have only themselves to blame for having done such a good job up to the point they have. :)
In reply to I recognize and acknowledge by Peter Schaffter
Beautiful response!
The subtleties of music will always demand way too much work, especially when you are trying to imitate the analogue nature of life with such a minimal tool as MIDI.
Keep up the writing.
In reply to The subtleties of music will by xavierjazz
There's nothing wrong with MIDI - everything is there in order to produce realistic sounding music, but it was designed for performance capture, not production from a score.
This is why it is usually much easier to export the MIDI data from MuseScore into a sequencer for further manipulation.
My workflow when creating orchestral backing tracks was first to write the score in Finale (I hadn't heard of MuseScore then) then export a MIDI file into Sonar 3 for further shaping of things like brass attacks and sustain shaping, also string sustains, because when a string or brass section sustains a chord the sound amplitude isn't static - it is shaped very slightly consisting of a curve from slightly quieter than the required amplitude, up to the designed dynamic marking and back again. Also the timbre of brass changes subtly on sustained diminuendos and crescendos so manipulation of the filter cutoff and resonance controllers is required.
Sequencers are specifically designed for the manipulation of performance data - score writers are not.
Not that I'm trying to belittle Peter's work - I think what he is producing with MuseScore is amazing.
I'm afraid though, that however much effort we put into the performance aspect of the music in MuseScore, it will still always involve a long and tedious process of tweaking minutiae to get the results we want.
In reply to The subtleties of music will by xavierjazz
I fear the title I gave my original post may be conveying the wrong impression. I expect a horrific amount of minute, note-by-note tweaking of the playback of scores created with Musescore because that is the nature of the computer-generated midi. There are, however, certain functions in Musescore, already in place, whose behaviour adds to the work, instead of reducing it, at least in 1.3. Those are the issues I’m raising, in the sincere hope they’ll be addressed in 2.0. My assessments are based on what’s improvable within the framework already in place for Musescore playback, not on the desire to change it.