There is a curious aspect of the ongoing Finale/Sibelius imbroglio in that the debate, at least partly, is too finely focused on sexy features or glaring shortcomings, and not on broader aspects of software depth and maturity, which frankly can’t be documented in a brochure. Additionally, the debate is both consumed by (and sometimes carried by) people who lack sufficient experience in the true depths of their own software to accurately assess the weight of the opinions they encounter.
Be honest, how many of us make fundamental commitments to important software, based on little more than a sales pitch or passive communal hearsay? Doesn’t that reveal a tacet acceptance of some form of “they’re all alike” or “I don’t really plan on getting too involved with this software anyway?” And then, once committed, how many of us actually put it through paces beyond what we immediately need to get this day’s/week’s/month’s tasks done? How many have gone through the manual, virtual cover to virtual cover? And, ultimately, how many keep tabs on the outside world for ongoing development by producers and aftermarket innovators? (And if one doesn’t, how does one sleep at night?)
I recently was asked by a friend and colleague for some help with a Finale problem. After a little probing, I discovered that it grew out of his own personally-developed shortcuts to the repetitive and time-consuming layout tweaks on myriad instrument parts for each score produced. The design of his workaround was not important. What was lay in the fact that, once his approach had been finalized and adopted, he had changed neither it nor the version of the Finale he had used in years.
Now I’ll be the first to grant that the pace and cost of upgrades can seem at times to serve software companies more than their customers. Depending on the needs of each user, the bang-for-the-buck factor in every upgrade can fluctuate wildly. I’m sure I’ve hardly been alone in wondering how some companies decide that it’s showtime (at least until I look at the calendar…)
But many of us seem to have developed a schism in our attitudes. When we perform, we take it as gospel that pursuit of excellence requires a constant struggle to improve both our tools (instruments) and our abilities on them. Pablo Casals, the legendary cello soloist, when asked by a friend why he continued to practice even into his eighties, had a reply that was telling: “Because I think I’m beginning to show some improvement.” However, many of us, when seated in front of a computer, drown that same restless urge in a vat of “If it ain’t broke, don’t fix it.” Professional or amateur, does it matter whether our tools are made of wood and metal or ones and zeros? A comfort zone of consistency often morphs into a dead zone of complacency and, in an arena of constant change, we don’t.
Notation software gets used because we hold out at least the possibility of an eventual performance, so we owe it someone to supply the best output possible. The look and feel of yours will speak both for and about you, and your mastery of the tools which generate it impacts on your overall reliability, competitiveness, and fulfillment in the process.
Any software package can misbehave in mid-gig, or turn out to possess insufficient headroom to let us go beyond its original design when the urge strikes us. In such cases we face three choices: complain, compromise our style or standards to fit the tool, or improvise. As the combinations of possible interactions in any complex system are simply too numerous, no team of programmers or beta testers can anticipate all contingencies. Neither can they provide documentation vast enough to even cover most of them (although, early on, Finale’s three bloated manuals sure tried…)
Hence, there is an added value to software which, by design or gradual evolution, packs sufficient assets to allow “more than one way to skin a cat” (gad, what a metaphor!) Along those lines, another barometer of programmer prescience is built-in capability for retasking (within the software) features by the user, with its promise of enhanced personal power when needed and appropriate.
Workarounds are a fact of software existence, but they should only have a life as long as the problems they address. With each upgrade, I go through my whole arsenal of macros and scripts to see which can be scrapped or adapted. When the programmers develop a better way, nine times out of nine-and-a-half their solutions are accomplished at more fundamental conceptual and code levels, and tend to be more elegant (and better behaving) than anything we can cobble together from the outside.
It behooves us, then, while perhaps not grabbing at every upgrade thrown at us, to at least keep a constant vigil on them for what they can do, and their potential for improving our user experience. Software producers, either through their online “what’s new” webpages and chatrooms or through freely-distributed demo versions, allow, no practically beg us to look under the hood and take a test drive.
And what of the “Fin-Sib” debate, and perhaps others? These issues of depth, redundant capacity, and retaskability and scriptability, while often overlooked, can yield greater depths to your evaluation of these competing products.
24 Comments