Today MakeMusic released Finale 2014d, the fourth maintenance release to the current version of the company’s flagship product. The release is notable because it’s the first Finale maintenance update since MakeMusic became a part of Peaksware in August of this year, under the leadership of new CEO Gear Fisher.
The update has a number of bug fixes and feature restorations made in response to user requests, including:
- An option to place hairpins in a way so that they don’t automatically snap to beats (as was the case prior to Finale 2014)
- An option for larger sized tool palettes
- Customizable tool palettes and other palette improvements for Windows users
- Improved speed upon opening and saving files
- QuickLook and Spotlight support on Mac
- Better support for movie files on Mac
- Fixes for Speedy Entry and Stem Connections
MakeMusic also announced that it will be discontinuing support for Finale 2011 at the end of this year.
Most interestingly, though, the release already bears the influence of the new leadership’s approach to software development by including an anonymous data collection component. The Help Improve Finale feature, which MakeMusic assures users will not collect any personally identifiable information and will not have visibility into actual documents, can be easily switched off at any time. It is designed to help the company “identify usage patterns so that [its] designers can make informed decisions when creating future versions of Finale.
In a post today on the official Finale blog, Gear provided details about software development, the upcoming move to Boulder (about 30 people from the existing Minnesota-based team will make the move), and announced the new MakeMusic leadership team.
I had breakfast a few weeks ago here in New York with Gear and two members of that team: MakeMusic product vice president Fred Flowerday and notation product manager Mark Adler. The trio was in the midst of a trip to Boston and New York during which they met with representatives from schools, publishers, and other customers. We talked about the future of Finale and the state of the music notation field, so read on for more about our discussion.
Collecting user experiences to guide development
Gear said to me, “I want to change the way MakeMusic is perceived in the industry.” When I pressed him further about what he meant, he explained that he wants to be “more transparent about what we’re doing, how products are developed and what we can do to improve the user experience,” and he used the new data collection part of Finale 2014d as an example.
“Of course we get lots of user feedback already, but it’s all anecdotal,” Gear said. “In order to make meaningful improvements in the software, we need for that feedback to be objective. We’ll actually be able to tell which aspects of the program people are using, and how often.”
He explained the utility of collecting and analyzing the data. “There might be lots of cool features that no one knows about that are buried several levels deep in the program. If we see that users are trying to perform a task a certain way, but there’s a feature that could save them time, we might be able to increase the visibility of that feature in some way so that it’s more prominent.”
Mark also pointed out that “it will be helpful for us to look at the plug-ins: which ones are being used often, which ones have some problems that need to be fixed, and which ones have been hanging around for a long time that could be deprecated.”
“With every Finale release,” Mark said, “there’s a rumor that we’re killing off Speedy Entry. It’s just not true!” Speedy Entry, of course, is the “pitch, then duration method” of note input popular among long-time Finale users and a feature that was newly included with Sibelius 7. He then asked me which version of entry I used, Speedy or Simple Entry. I replied that I probably use Speedy Entry about 80% of the time and Simple Entry the remainder of the time, mostly for repitching, but I wasn’t quite sure if that was accurate.
“Wouldn’t it be great to know?” Gear asked, illustrating the potential of having the data available to scrutinize. “Look,” he said, “this is not about being lazy and asking users to do the work for us. There just isn’t a way to objectively know how people are using our product unless we directly collect the information about which tools they click on and which tasks they do.”
Gear explained that different features have different purposes, and it’s not just the quantity of use that matters. A feature that has widespread but rare use is just as important as one that maybe only 20% of people use often. “Think of something like the e-mail auto-responder in Outlook,” he said. “That’s something you might only use a couple of times a year when you’re away on vacation. But nearly everyone uses it.”
Fred said that they realize that they won’t be able to learn everything about product development from this data, and that they’ll have to interpret the data wisely. “It’s entirely possible that something isn’t being used, not because people don’t want the feature, but because it’s poorly implemented.”
I cautioned against relying solely on user feedback to drive improvements. I mentioned Sibelius 6’s introduction of ReWire as an example of a feature I didn’t even know existed, yet now find indispensable when working with orchestrations and transcriptions. Gear agreed, citing the quotation apocryphally attributed to Henry Ford: “If I had asked people what they wanted, they would have said faster horses.”
However, Gear said, simply “putting out new features and waiting to what feedback comes in is an inefficient way of developing software, and that’s what I mean about being more transparent to our users and improving the company’s perception in the market. When you get updates for apps on your phone, or for modern web browsers like Chrome and Firefox, they’re frequent and you don’t even think about it. You just download the update without being fraught with apprehension about what or wasn’t included; you might take a look at the ‘What’s New’ document and then get on with your work. That’s where I’d eventually like to get to with MakeMusic’s products. What we won’t do is be beholden to a yearly ‘major’ release cycle like we used to do.”
MakeMusic’s products, open standards, and competition
Fred & Mark are accomplished engravers and musicians themselves, and they were quick to point out that the development teams are now being headed by people that actually use the software for their work in that capacity. Fred asked me in which version I do most of my Finale work. When I replied that it was Finale 2012, not Finale 2014, it did not come as a surprise. “We fully know that there are many things that need improvement,” he said.
We all had high praise for the work that Finale user Jari Williamsson is doing with his freeware plug-ins, and Fred acknowledged that some of those features “should, frankly, be things that Finale can do on its own.” Moving with the company to Colorado is, Fred said, “a tremendous opportunity for us to refocus our efforts on things that should have been done for quite some time.” Gear said that the transition is on track to be completed some time in the first quarter of 2015.
We discussed MakeMusic’s interactive music software SmartMusic, which shares Finale’s notation engine. “I’d love to get SmartMusic to a point where it’s not just a music education tool, but it’s a music publishing platform as well,” Gear said. “For that to happen, there needs to be a critical mass of music available so that students and other consumers can find anything they’re looking for, and it encourages a virtuous cycle where publishers want to make more music available on SmartMusic.”
MusicXML continues to be important to MakeMusic as a means to allow people to more easily transfer music among different notation products, but whether or not MusicXML remains a part of the company in the long-term was less relevant. “Because the music notation software market is divided,” Gear said, “sharing files between users across different platforms and versions is difficult,” and from this the need for MusicXML arose. He also said that the continued development of MusicXML may ultimately fall to the standards community like World Wide Web Consortium (W3C) or the MIDI Manufacturers Association (MMA).
About another company-owned open standard, Steinberg’s relatively new Standard Music Font Layout, or SMuFL, Mark said that MakeMusic plans to support it in a future version of Finale. “I’m well on my way to mapping Maestro to SMuFL, and the Engraver font will be next,” hopefully followed by other fonts as well, Mark told me. “We’ll continue to support the legacy fonts, but in our early testing, SMuFL in Finale is working well.” He also pointed out that Bravura, the flagship SMuFL font, shares its provenance with Finale’s Maestro, as both are digital versions of Not-a-set.
Regarding Steinberg’s eventual entry into the market, Mark and Fred paid them professional respect, saying that their development team is very talented. Gear agreed, and added “I would love to be able to start from where they are, with no technical debt.” But, he added, “the music notation market is not expanding. With Finale and Sibelius well-established, they have a challenge ahead of them. I do think, though, that the more people there are in our field working and thinking about these issues, the better it is for everyone, especially consumers.”
The trio acknowledged the limitations of a small company in that niche market in supporting many legacy versions of its products. “We don’t have the resources of Adobe or Apple,” Gear said. “I’m focused on making Finale 2014 better, and if that means a 2014e or 2014f, that’s what we’ll do.” He clearly stated that there would not be any more updates for Finale 2012 or earlier.
However, Fred pointed out that that they fully understand that many people rely on music notation software for their livelihood or education. “It has to be as good as we can possibly make it. We were in a recording studio recently and we actually did a calculation of how much money per minute was being spent on the session — on the order of hundreds of dollars per minute. The music has to be right so that the money isn’t being wasted fixing wrong notes!”
Wheat Williams
What did you learn about the future of Garritan Virtual Instrument Libraries, which is a division of MakeMusic?
George Litterst
I am interested in this question as well.
Gregory Winters
I would like to see Sibelius move away from being an application of features and functions to being more of a real tool in the hands of a competent musician/composer: *controlled* by the user rather than simply ‘operated.’ Software has got to go from being a collection of millions of lines of (allegedly) logical programming code to a heuristic engine that ‘learns’ from its user and assists the user with the tasks that s/he needs to accomplish. Yes, horse owners couldn’t conceive of the automobile, so the point about introducing futuristic features in software is well-taken. However, the first ‘automobiles’ were fashioned directly from carriages (and named “horseless carriages”) and the ‘new functionality’ was introduced gradually and intelligently enough to permit users to ultimately make the switch. The kind of folks who would jump on the ‘gadget approach’ to music – jumping on features for the sake of novelty – are more likely to use DAWs and other similar tools for composing and not an application that purports to represent a discipline which is centuries old.
The application’s interface should actually adapt itself over time to a user’s style and preferences, so that the user would not have to repeat him/herself so incessantly in every phase of the composing experience as we do now. Oh, the other options would still be available, but those which the composer uses more frequently would be either more readily available in the interface or the user wouldn’t even have to instruct the application as to what to do. No, I’m not talking about customizing ribbon bars – I mean full ‘Hal-like’ interaction with the user, automatically understanding where to store and retrieve certain types of files, being able to change chord spellings to suit an edited variation, assemble a theme of text and display settings that the user prefers without having to use ‘templates,’ understand strumming patterns for guitar and learn how these apply to tablature and notation displays which can be realistically performed by people with normal-sized hands, apply motifs from one score to the next and shed once and for all the shackles associated with the arbitrary ‘file systems’ of microcomputers, and countless other tasks.
At its root, the application would be a multi-layered database of data and features, but at the portal, it would be one massive ever-live macro, always gaining intelligence and insight into the user’s desires and habits. It eventually would take over most of the menial tasks of composing and managing the output, able to perform batch processing, understanding how and why humans share output data with one another. No question that a user asks would ever go unanswered for long because the answers would not have to be written in with more lines of code, but instead would be the result of the application’s analysis of the scenarios and environment the user works in.
More importantly, the application would absolutely have to know what a user is attempting to accomplish. The whole idea of ‘help files,’ ‘reference manuals,’ and the like is a testimony to the sad state of quality of interaction between user and computer. In no other industry are there so many blogs and forums of distraught, disgruntled, and disenfranchised users as in the world of small computer software. Instead of using a tool whose interaction is largely transparent where we can concentrate on our musical ideas, there are huge numbers of us being forced to be ‘computer geeks’ to learn the fine nuances of the guts of the notation software – only to see what we learn become instantly obsolete with the next release or interaction with some other component. Thus, I present Rule #1 to this end: At no time – EVER – should a user attempt to do something more than twice without the system understanding what it is that is being attempted and providing detailed feedback as to why it is refusing to obey the commands of its Master, along with an offer to override the present configuration and obey the instruction. Those of us who have been around computers long enough know that an application routine exactly knows where it fails/halts…and what it was attempting to do when it did. This should become part of the user’s toolbox to see the issue through.
Example: If I add a note to a drum staff in Sibelius and indicate that I wish to hear the sound, I’m not just doing this for fun and games. I want to hear that sound. After all, I’m hearing all the *other* sounds so far in the score. However, if I click on the sound and there is no sound, the application should be fully aware of this (and it is, believe me). It needs core functionality that checks the sound process from end to end so that there can only be *physical* reasons why I’m not hearing sound: (speakers unplugged, amp not turned on, etc.). At no time – EVER – should there be a ‘virtual’ reason why I’m not hearing sound. This is not an invented story – according to Google, this happens to countless users all the time with Sibelius. The typical process of solution by software developers, however, is: determine if the pain level of the collective user community is severe enough (i.e., will leaving the problem alone result in the sale of less licenses?), and if it is, then write something for *that specific problem* into the next release of the product. Over time, the application becomes a top-heavy mish-mash of features to solve this and that and this and that and there is never a question as to how, after all those releases, that there is still such a huge problem with bugs and confusion.
Instead, the heuristic solution would be to architect the application so that what it knows *behind* the scenes is revealed to the user *up front*. If I tap on the drum sound three times, say, then the interface comes up and says: “The note you are asking me to play is not part of this drum kit. Would you like me to add it now?” Or: “There is no sound assigned to that line/space in the staff for this particular instrument. Would you like to assign one?” Etc.
The upshot is that users would only need to learn as much about the application they use as they need to, not have to become experts in the software just to compose a simple score. For example, I’m sure that there are those who appreciate the Retrograde Staff feature in Sibelius, but it’s something I doubt that I’ll ever use. However, it sure would be nice if Sibelius could learn – *automatically* – my style of composition, the layout spacing I prefer, how the layouts of my parts compare to the score, where certain types of finished products are stored and how they are shared, and a host of other time-saving and error-reducing tasks. More importantly, however, is that Sibelius should never appear to be obstinately disobeying my commands and assist me with learning what I must do to help it do what I ask it to do. Make Sibelius understand that WYSIWYG is God (e.g., if I position text in the score relative to a number of musical elements – which is how a composer does things, then Sibelius would ‘learn’ these relationships and not send the text flying all over the place due to some arbitrary coding scheme, as it does currently). Whatever the user sees on the computer screen is Sibelius’ absolute command and at no time should it change.
Heuristic learning and full instrumentation of the application. That should be the future of Sibelius. Thanks for listening!
Bill
What’s that have to do with Finale?
John G
And still absolute silence about Garritan Virtual Instruments. We now hear that Gary has left Make Music as from late 2014.