The future of Musescore
Hello everybody,
I have just spend the last couple of weeks working on some musescore stuff from the source, partly for my own benefit and partly with the hope that I could make a contribution. I have been working in the software business since 1982, mostly on large projects, and I thought my views as an experienced outsider may be useful.
It seems to me this project has reached a very interesting moment in it's developement. After much hard work, the current 'public' version - 0.9.6 - is really very good. From the point of view of musicians and educational institions, it is a real alternative to sibelius, finale etc. It has an intuitive easy feel, it's stable, it does a good job, musicians can do stuff on it.
The development team saw that this version was just two good to let go of with a release of a v1.0, and I think they are quite right.
At the same time the unquenchable lust for new features from the users who would like it to do that little bit extra, and the passion of the development team to write new stuff has lead to two versions, the one mentioned above, soon to be 1.0, and 0.9.7, also known as the trunk, in which development speeds on. I've looked at the code, and really a lot has happened since 0.9.6
But what next? I foresee two versions in the near future - v1.0 and the trunk - so different that the idea of simply stabilizing the trunk and using that as the next version of v1.0 may not be feasable or advisable.
Open source guys have a double motive: On the one hand they want to give the community an excellent product which can rival the commercial stuff, and on the other they want to develop what interests them to develop - and they aren't being payed so why shouldn't they?
The trouble is that the two motivations can come into conflict, and I believe musescore is current dealing with this dilemma. I think you've done it rather neatly by putting the first motivation into v1.0 and the second in the trunk.
So, what I think happens next is that v1.0 after it's release continues a slow and very careful developement, while the trunk races ahead to form maybe even a different project. Successes of this new project can maybe sometimes be plowed back into v1 development, but only after much careful consideration.
For a product to be successful from the users point of view, it must be stable, at it also should be clear what it is - what it can do, and what it can't do. The limitations are always frustrating, but there must be limitations - the products which try to do everything end up as monsters - in the commercial world they can be billion dollar turkeys, and there have been plenty of them, I've seen a few.
What's so great about v1.0 in my eyes is it seems clear how it's limits could be defined satisfactorily. It is primarily music notation software which has the ability to transpose, and be played as audio. It should be able to produce useable parts for ensembles and soloists, and you should be able to play along with it. If better sound is required, either midi out or midi export can be used. If more subtle scoring is required, this should be pastable as pure image without midi interpretation.
Musescore v1 does all that, apart from the midi out. I have developed a midi out driver for v1.0, which I attach (only tested on windows it's a patch for r3864), which maybe can be used one day.
One possible exception to the above may be OMR. But what's needed is a careful examination of what most people really use musescore for.
Anyway I think this is the most import discussion for the General Forum. Not the request of new features, but addressing the questions - where do we go from here? and what is Musescore really for - the correct limitations as well as feature set?
Hope this helps
Richard
| Attachment | Size |
|---|---|
| PortMidiOut01_r3864.patch | 24.65 KB |
Comments
Thanks for your comments and insight based on your experience. I have to wonder, though, to what extent your views reflect those of the rest of the developers? I have not gotten involved in development at all - my time is too limited, my programming skills too out of date and rusty. But I *have* been following some of the developments on the trunk, both through to mailing list and by checking out nightly builds from time to time. And I just don't see this conflict you describe at all. It looks to me like the features being added are pretty much *exactly* the ones that users do indeed need.
I have no problems with the way you've defined the basic purpose of MuseScore, but I think you're greatly understating the extent to which 1.0 actually addresses that purpose satisfactorily. Don't get me wrong - it's a *great* program for what it is right now. But 0.9.6.3 - and hence, presumably, 1.0 - still has some pretty serious limitations. And I am not talking about doing things *other* than what you describe as the purpose of MuseScore. I'm talking about how *well* it fulfill that purpose. Calling it "music notation software" implies one should be able to use it to efficiently create notated music, and obviously, one *can* do this. With sufficiently simple pieces - just a couple staves, limited use of parts of voices - you can even do it as easily as in other software. But when you try to deal with large scale / more complex pieces - still using nothing but traditional notation - you start to run into limitations where you really need some additional features in order to work as efficiently as Finale and Sibelius have shown is possible. And as I see it, development on the trunk *is* addressing those limitations and adding features that will help with large scale / complex pieces, exactly as I would hope would be the case.
So I'm a bit mystified as to where you see the conflict between what users want and what developers want. Is every single feature on my own most wanted listed already being implemented on the trunk, and vice versa? No, of course not - but I'm not so naive as to think my own needs are exactly the same as everyone else's.
In reply to Thanks for your comments and by Marc Sabatella
I must admit I haven't tried to understand the development roadmap. I've seen "the trunk" mentioned but not bothered to find out about it. I have also tried out a couple of nightlies to check out a new feature. But I'm not at all clear as to what will be in v1.0 - I'd assumed it would simply grow out of the nightlies, which in turn I'd assumed were based on the current live version. Is that not the case?
I'm also an ex "large projects man" and as such I'd be a bit concerned if there are effectively two parallel developments going on as at some point they'll need to be merged - unless they end up as separate products as Richard suggests - and that's not an easy process. It makes testing much harder (especially regression testing) and that's essential for stability, robustness etc . It's also quite common in large projects that lack formal management structures for bugs to be introduced during final testing as people run around trying to fix reported errors and you can easily end up chasing your tail.
This isn't meant as a criticism of the development team, I'm sure they know what they're doing and maybe system building has moved on from the mainframe environment I was brought up on so I might be talking out of my backside
Can anybody outline the future plans for Musescore for me or point me at the resources that I've not been able to find yet that will clarify it for me?
thanks
In reply to I must admit I haven't tried by fatwarry
Just to set the record straight, there are no two development tracks. There is a branch maintained by lasconic which will become MuseScore 1.0 and there is the trunk maintained by werner which eventually will become MuseScore 2.0. The branch will be further maintained until MuseScore 2.0 is released, but only for critical bugs.
For more insight, read this thread on the developer mailing list: The roadmap to MuseScore 1.0.
In reply to Roadmap by Thomas
My views are personal, I don't believe that the main development team agree with me.
I can see that there are not two different development tracks, in that there are no plans to do development on v1.0 apart from critical fixes. But there are as of now two different code bases. People who report non.critical bugs in the v1.0 branch are being told "it's fixed in the trunk" which means "wait for v2.0 or go to the bleeding edge (nightly builds)" - but if the users are looking for stability, I would suggest they stick with v1.0 for the moment. And when will v2.0 become as stable as v1.0?
We all hope that v2.0 will simply be like v1.0 but so much better. But software doesn't always get better when it gets more complicated. I am sometimes nostalgic about the old days of Cakewalk, when it could only do midi, and I learnt it in a day. Now it's grandchild Sonar is a different matter, and I pity the not-so-computer-friendly people who are trying to get to grips with it.
All the new features will be welcomed by someone. The one which I came to question was the ability to use multiple synthesiser modules. I would have thought having the synthesis done on the other end of a midi connection would have kept this complication out of musescore.
I think musescore v1.0 is easier to learn than Sibelius. I haven't tried finale. I actually don't want it to be so feature rich, but intuitive and simple to use, something which doesn't take too long to learn and is above all stable. Of course there are many who have different wishes, but am I really a lone voice? I would love to see v1.0 cautiously developed, but there we go.
What I want and what Marc and others want (see above) are clearly different, incompatable even. But what do the users out there want - those 80000 a month who are downloading as we speak? Does anyone know? How can we find out?
Richard
In reply to My views are personal, I by Richard Green
I don't think we want different things at all. I value ease of use too. That's precisely why I think significant improvements in the facilities for handling large complex scores, and that's exactly I'm pleased with things like linked parts and many other features on the trunk. Sure, I also value stability, and never nothing I've written should be taken to imply otherwise. That's a straw man, pure and simple. And you say you don't want Musescore to be "feature rich", but clearly, you want it to have sufficient features to allow *you* to get *your* job done, and in any easy to use manner. Well, that's exactly what I want, too - enough features to allow *me* to *my* job done, and in any easy to use manner. And I'd argue that's all *anyone* wants. But it's lunacy to assume that the features you need to get your job are the only features anyone needs to get their jobs done.
On the other hand, I'm not even convinced the jobs I want to get done are any different than the jobs you want to get done. I personally couldn't care less about supporting multiple synths (but nor do I begrudge someone else that need). I need part extraction and formatting to be much easier than it is - and that's happening on the trunk. I need better facilities for manipulating voices - and that's also an area that seems to have some development interest. I want more and easier customizability over the appearance of my scores - and that is also something happening on the trunk. And I find it hard to believe anyone would argue against things like this. These to me *are* the essential features of notation software.
As for making a list of user-desired features, I would start by assuming this: people want everything that Finale and Sibelius offer, but they want it cheaper. You'd have to have an extremely good reason to believe some particular feature in Finale or Sibelius is *not* wanted by their customers, or that their customers are not MuseScore's customers. If it's in finale or Sibelius, it's pretty likely that MuseScore users will want it too. And indeed, the features I mentioned above *are* the sort of things that have been requested many times over here. So there's really no doubt at all that these are wanted features. I'd go so far as to call them "no-brainers".
As for monitoring what MuseScore users have actually expressed interest in, there is a whole forum full of suggestions.
In reply to I don't think we want by Marc Sabatella
The trouble with users expressing there wishes in forums is that it gives the appearance that people want new features, since the people who are already happy with the feature set tend not to post. Also those who post are the minority naturually - but are they a representative minority?
Of course it may be that it's the best we can do. But it would be very interesting to know if any educational institutes have opted for musescore, and if so why. Maybe it's not just the price? Maybe it's easy to teach it to beginners etc?
You say you don't care if there are extra features in there, and I can see your point, but I am worried that all extra features add complexity which can easily make for stability problems, especially without a big testing budget. Having said that the developers at musescore are pretty good, so maybe they can pull it off.
In reply to The trouble with users by Richard Green
Richard,
For a list of educational institutions that have opted for MuseScore see http://musescore.org/en/about/references
For some of the reasons that people have opted for MuseScore see http://musescore.org/en/about/testimonials
The developers regularly read the forums. The most important features aren't just listed in the "feature request forum", they come up in conversations all over the place. And of course I should mention that just because a person asks for it doesn't mean that it is the best direction for MuseScore. To give an example: support for importing LilyPond or Finale files comes up from time to time, but instead our focus is on import and export of MusicXML. This particular issue is mostly a matter of resources and practicality (MusicXML is a better use of developers time). Other requests are not supported because it is not a primary purpose of MuseScore and supporting it would hinder MuseScore's focus on basic notation, or there are other projects tackling the problem (RoseGarden as a Digitial Audio Workstation for example).
In reply to Features and education by David Bolton
Thank you, the references and testimonials were very interesting, I hadn't found them, I was looking through the forums.
I am glad that you are carefully considering which features to add and which not, I think that's important. I hope I don't come over as a critic, I, along with the testimonial writers, am a big fan of v1.0. I was only wishing to give a word of warning - that when one has a good product, one has to be very careful when one 'makes it better'. It is almost inevitable that when a program becomes more complicated it becomes more difficult to learn. The testimonial writer who wrote ' I am by no means a professional musician, but I wanted to be able to write some simple music without buying costly software' may prefer v1.0 to v.2.0 even when v2.0 is stable.
You mention that your choice of what to include also 'come up in conversations all over the place', not just the feature request list. You know the range and breadth of those conversations, and you have a way of deciding what to develop. That decision process is going on within the development team, people like me don't get to see it. When I raise the issue, I don't want to criticise that process, only to make it more public, to join in with it.
I thought it would be a good idea to have a open debate about what should or should not be included in future versions of musescore, and my personal contribution was to favour a 'less is more' approach. I believe I stand for some of the testimonial writers who praise v1.0 for it's ease of learning and use. Either this is a matter to be discussed, and I am more than likely prove to be wrong, or it is a matter for the development team and public discussion is inappropriate. I only hope to raise the questions.
In reply to Thank you, the references and by Richard Green
Hi Richard,
For many years now, the mantra of MuseScore has been: it's free, it's easy to use and it creates beautiful scores. This has so far not shifted, what's more, I dare to say that the MuseScore project gained even more focus. I'll address each one of the points to give you some insight on where we come from and where we are heading to.
MuseScore free
MuseScore is free as in beer as in speech. This is the basis why MuseScore has become a success in the first place. So above all, we want to preserve this. How we want to achieve this? Read all about it at http://musescore.org/en/node/8099
MuseScore is easy to use
Music notation software is not the easiest software to learn. You need to have some basic knowledge of music theory and it takes some time before you handle the software. During the past years, the community has been putting a lot of effort in lowering the barrier to get started with MuseScore. The result:
All these elements together result in the fact that people experience MuseScore as easy to use. And now I come to your question and that is how we can preserve the easy to use aspect for the future.
Let me start by saying that we are all familiar with the pitfall of feature creep or featuritis. It's not because MuseScore is an open source project, that this means that it is more sensitive to feature creep. The overall design of MuseScore is done by committee and it's Werner in the end who decides what gets committed to the code base. And so far so good, not?
We defined two major features which will enlarge the adoption of MuseScore: tablature support and linked parts. The former reaches out to the low end side of the sheet music market, while the latter goes to the high end side. To implement both features, MuseScore needed to be refactored and the result is what you see today in the trunk. It has been accepted well, as featured in this Examiner article.
The inevitable result of the refactoring is that the trunk is unstable for the moment. But that will be addressed soon. After the release of MuseScore 1.0, we will focus completely on the trunk and release a prerelease asap. At a certain point we'll do a feature freeze, a string freeze and finally come out with a new stable release. And then the cycle will restart.
MuseScore creates beautiful scores
In the MuseScore project, the primary focus has always been on typesetting. Playback comes second. And that will remain for the time being.
I hope this explanation will reveal a bit where we go with MuseScore. If you want to hear what Werner has to say about MuseScore, you may be interested in this recent interview.
In reply to Some more insight by Thomas
Thanks for the responses. I think musescore is in good hands.
In reply to Thank you, the references and by Richard Green
Again, I agree - ease of use is of absolute paramount importance. And sure, no one likes big bloated software, But I guess I don't really fear either of those becoming a problem here. I think the project has pretty clear direction from what I can tell.
And really, it's ease of use - not additional capabilities per se - that I think can still stand the most improvement. As I've been saying, creating simple scores is certainly easy enough. But creating larger & more complex scores is much harder than it currently is in Finale or Sibelius. As big and complex a piece of software as Finale is, they've made *huge* strides in ease of use in the two decades or so they've been in business (mostly because they've been copying features from Sibelius). And not just in the creation of large/complex scores, either - the entry of simple pieces has *also* come a long way since the 90's versions of Finale.
So, contrary to your concern about new features impeding ease of use, in the case of Finale at least, it's very much the other way around. Don't get me wrong - it's still not as simple as MuseScore for some tasks. But compared to where it was in the 90's when I first started using it, it's really come a long way. And just as Finale has learned from Sibelius (and to a lesser extent the other way around), I think MuseScore can still learn from both.
So anyhow, I'm personally not bothered by any of this discussion. I think a reality check is a good thing, both for the developers in maintaining their focus, and for the rest of us users as we consider our own requests.