Roadmap for MuseScore 2.0
A week ago, I was at FOSDEM with Thomas and Werner to promote MuseScore to fellow developers, to new users, and to husbands, fathers of new users. Here are some photos.
It was a great opportunity to discuss the future of MuseScore and the remaining work to release MuseScore 2.0. I sat down with Werner and we came out with a MuseScore 2.0 roadmap. The list is probably incomplete, and will move but at least we now have a list on paper! We will extend the list, prioritize items etc... This list is a basis for further work. If you spot a missing item in the list, please report it.
One of the purpose of this list is to be able to locate features that are still under heavy development. These features don't need testing just now but as a tester, your opinion about the interface, the importance of the feature etc... is very valuable. You can post your feedback in the Technology Preview forum
The list also contains, and will hopefully contain more and more, completed features. As a tester, please test this features in priority and submit bugs in the issue tracker. If you are not sure if it's a bug or expected behavior, you can discuss it in the Technology Preview forum.
Happy testing!
Comments
Since there has been no feedback on this, let me just say, thanks for doing this! I have been too wrapped up in various other short term projects to spend much time with 2.0 builds, but am looking forward to doing so this summer, and contributing what I can.
hi, it would be very interesting if musescore could address sounds & articulations & dynamics by midi - and if these could also be programmed or adapted by hand resp. via an intercative user interface. thanks, marco
In reply to midi by madweb
There is already something implemented in MuseScore 2.0 somehow. Each chord has a menu named "chord articulation" where the midi data can be changed. I will add it to the list...
In reply to There is already something by [DELETED] 5
Why not working with Vienna Symphonic Library so Musescore is 100 % compatible with VSL, you will have a lot of clients !
All Logic clients that are fed up to wait that Apple implement articulation changes in Logic !!!
Best
Cyril
In reply to why not working with VSL by cyrilblanc
Whilst I accept that playback is important.
I cannot support improvements made in playback before tackling some of the problems with entering notation.
The current chaos regarding copy and pasting is an example.
When all is said and done VSL is merely a sample set, and we have a perfectly good sample renderer in the Fluid soundfont engine.
Perhaps the way forward would be to produce a VSL->Soundfont converter?
In reply to Whilst I accept that playback by ChurchOrganist
> Perhaps the way forward would be to produce a VSL->Soundfont converter?
I doubt you have an equivalent of VSL, but I will give a trial when I return in one week.
Do you have as much articulation as VSL BIG collection ? Do you have MIR in 7.1 ?
VSL will not convert to SoundFont, all you need is to sent an articulation follow by a midi note.
Is Musescore compatible IAC ?
I see Musescore controlling VSL either by IAC or by integrating the various AU or VST that has VSL
You need to build a table to convert articulation changes from Musescore to VSL for each instruments
Best
Cyril
In reply to > Perhaps the way forward by cyrilblanc
MIR??? IAC???
Google doesn't give a relevant hit for either of these acronyms.
Musescore is not VST compatible.
It uses Soundfont technology for rendering samples, amd this is unlikely to change for the foreseeable future.
Also it currently doesn't support the playback of many articulations, although I believe that is being addressed in 2.0
In reply to MIR??? IAC???Google doesn't by ChurchOrganist
Hi
Your Google is different that mine !
The IAC (Inter-application communication) Driver in Mac OS allows you to create virtual MIDI cables between applications inside the box, so to speak. This lets you share midi information without the restrictions of Rewire!
How to use the IAC Driver : http://sites.google.com/site/mfalab/mac-stuff/how-to-use-the-iac-driver
So for Musescore it will send Midi to VSL as VSL was a synth !
MIR : visit VSL site http://www.vsl.co.at/en/211/497/1687/2002/1691.htm
I just bought MIR, it's fabulous it is like you where in the concert hall, and the cherry on the cake is you do no need to EQ
Are you one of the develloper of MS, if yes speak to VSL people they are very good support@vsl.co.uk and speak to Martin
Best
Cyril
In reply to MIR IAC by cyrilblanc
Ah - I wondered if it was Mac stuff.
All my DAW experience has been with Windows or Linux.
I'm not one of the developers - sadly my programming skills are too old - Pascal, Delphi etc
I contribute to the project by testing, giving help and support and producing video tutorials.
The dev team do read these forums though.
But please bear in mind what I said in my first reply to your post - playback issues are currently being regarded as secondary for the main part, while there are still notation entry and display issues to be dealt with - of which there are many!
Regards
Michael
I added 2 items in the roadmap :
In reply to I added 2 items in the by [DELETED] 5
FWIW, it's not just orchestral scores where scroll view would be useful, and in fact, orchestral scores are ampng the *least* likely type to benefit, since they are almost invariably one system per page anyhow. It's scores for small ensembles, or piano scores, or lead sheets - music with several/many systems per page - where a scroll view would be most useful. No more starting to enter notes on the last measure of one system only to have the measure become too full to fit on the line and thus jump to the next line, and continue jumping back and forth from the end of one line to the beginning of the next every time you add or remove an accidental or otherwise make an edit that alters the length of the measure. With large ensemble scores, the same thing happens, but the beginning of the next lone is already visually right next to the end of the previous line, so it isn't quite as distracting. Not that it wouldn't be beneficial, but the main benefit would be for lead sheets, piano, and small ensemble scores.
In reply to FWIW, it's not just by Marc Sabatella
Indeed. Fixed.
In reply to I added 2 items in the by [DELETED] 5
Cool :)
For me one of the most important things is better copy-paste behavior.
I actually (since 1 year) teach MuseScore at the Conservatory in Ghent as the default Music Notation Software, since I think it's a great program with lots of potential, it's free, it's cross platform and, especially for users who don't need to create large orchestral or heavily complex modern works, you can create very nice scores with it.
Unfortunately, the school has a history of Sibelius (nothing wrong with that of course) but a lot of students are still very sceptical towards a "free" Notation Program. "Why don't we learn Sibelius, that's an industry standard, it's professional!" is a comment I often get. I've noticed there's a bit of snobbism towards small, nice, open source, free software, but since MuseScore is only in version 1.1, there's also (sometimes) a bit of truth in their complaints.
Because while I'm able to defend MuseScore to a certain extend (as long as we don't go into orchestral works with parts and empty staves that should be hidden where MuseScore (let's be fair) totally loses it), the MuseScore copy-paste behavior sometimes drives me (and the students) slightly mad. When I create something and carefully change the way it looks (the direction of a beam, the length of an octava line or a slur,...) and then select it, hit ctrl+c, go somewhere else and hit ctrl+v I want MuseScore to simply copy what I've created and put the exact same thing somewhere else...
The way it's working now is that some things (a lot of things?) simply CAN'T be copy-pasted (lines, expression marks, chord symbols... anything but notes, correct?) and things that CAN be copy-pasted (notes) often look totally different after pasting...
So for me, before fancy playback of tablature or anything else, please first fix this rather basic (I know, probably very hard to program, but still "basic" :-) software behavior.
Meanwhile I'll keep defending this software and try to convince people to give it a chance (by carefully selecting my example scores and omitting current problems...
Regards,
Senne
In reply to For me one of the most by Curls_On_Keys
Hey Senne,
Thank you for your comment. Your critique is very valid and justified. We still have quite a way to go to make things better. I'll take the copy-paste issue with me as a focus point for 2.0.
In the meantime, don't stop evangelizing MuseScore! I hope to join your classes one day :)
In reply to For me one of the most by Curls_On_Keys
BTW, I agree there is a lot of room for improvement here. But for the record, it isn't just notes that copy - it's also chords, lyrics, articulations, and perhaps some other markings. Also, while stem adjustments don't copy, some other properties do, like notehead shape changes, nudges left or right, beam breaks and joins, etc. Really, I'd say more things do copy than don't, but it's true that lines don't, nor do some other markings like text other than chords/lyrics, also measure-attached markings like codas, and certain manual adjustments to notes like changes in stem length.
Anyhow, no doubt, more control over this would be an excellent thing.
Each release (obviously) becomes better with the pile of fixes and features offered (even if it isn't very frequent).
If there's doubt, perhaps you could discretely advise your students to wait and reserve judgement until the next major release (2.0 - coming this year) and onwards. With the amount of changes, I believe it'll gain more reliability and credibility for everyone, from students to professionals.
There are many reports filed (see the Issue Tracker) and just awaiting fixes, thanks respectively to the large community of forum users and the small team who work tirelessly through them.
On account of everyone's different uses of MuseScore, it's always helpful to have other perspectives. One idea could be to ask students if they encounter issues, to report them to you (with instructions on how to reproduce). After, you could search to see if it exists and if not, file a report .
It's one way to help improve things :).
Hello,
First of all, a big Thanks and congratulations for the great work on Musescore.
I would like to point out here a feature, that would appear very useful to me, already discussed in the following threads about 1 year ago :
http://musescore.org/en/node/9748
http://musescore.org/en/node/9375
which concerns the ability of inputting the durations in a first step, and then the pitches (via midi keyboard for instance, but without reinputting durations between each midi-keyboard entry).
Apparently, the feature has already been worked through but does not seem to be available on Musescore 1.1.
Will it be on 2.0 ?
Thanks again!
F
In reply to Repitch Mode by skorqa
Yes, there is a start of repitch mode in MuseScore 2.0. I will add it to the list since it might need testing.
One thing you might consider is having the roadmap extend past 2.0, to make explicit where you are thinking of drawing the line at adding new features. As a user, it's always natural to want a requested feature implemented sooner rather than later, but of course that ends up being self-defeating, as implementing more and more features for the next release just delays the release. I think the current roadmap describes a 2.0 that is already worth having as soon as is practical, without much if anything more than is there now (already implemented or planned according to the roadmap). While there are additional features I'd love to see eventually, I am pretty sure I'd prefer to see an earlier 2.0 release without those features than a later 2.0 release with them. But it would be nice to see features that are acknowledged as probably worth doing eventually - just not for 2.0 - listed somewhere. Obviously, there is the issue tracker, but that doesn't really record any plan for when the feature might be added, nor does it differentiate well between minor tweaks and major new features.
I started to post a list of the "big ticket" items I thought most worth mentioning in this context - things I wouldn't want to hold up 2.0 for but that perhaps deserve a place on a post-2.0 roadmap. But I don't know that this thread needs to be de-focused with a lot of specifics like that, and the inevitable back and forth over what really is worth pursuing for 2.0 and what is not.
Something I could see myself doing - if you thought this useful - would be to comb the forums and issue tracker to develop a list of the "most important" requested features. Where "most important" might mean they were requested most often, requested most vocally, most fully worked out in terms of how they might work, or if in my judgement they'd make the biggest difference, etc. Obviously, that's pretty subjective, but I don't think a completely exhaustive list of every feature ever requested does much good here, and I'd like to think I've got a pretty good read on what might be considered "important". Of course, I'm not saying I should have the sole say - if others want to participate in this process, great!
The end result would be a user-directed list of most important requested features, and then the development team could sort out what they think would actually be worth "committing" to at least considering, by listing those features on a post-2.0 roadmap.
In reply to One thing you might consider by Marc Sabatella
To be clear, in the 2.0 roadmap page, I listed things that are already partly implemented in the trunk and things Werner wants to solve for 2.X. Drawing a line between 2.0 and 2.X would be useful, but it's indeed not done, and I believe it's more a technical issue than a user issue.
So now there are two kind of features, the one already partly implemented that I forgot to add in this list and the one not partly implemented and then not listed. For the first kind, I would like to add them to the list. For both type of issues, they need to be identified. So a forum post or a page to list popular feature requests is welcome!
In reply to To be clear, in the 2.0 by [DELETED] 5
That makes sense. I've got a bit of spare time coming up over the next few of weeks and may try to get started on making a list. Actually, I've already started on over on Google Docs, just off the top of my head. And FWIW, improved copy/paste facilities (ability to control what gets copied and what doesn't, including voices) is high on that list.
In reply to That makes sense. I've got a by Marc Sabatella
I think this feature it's cool but has been implemented in the wrong way. Instead of building the synchronisation inside musescore, I would have preferred that Musesc. gets full Jack transport support. Jack is a professional audio driver, transport (playback) synchronisation tool and audio and midi connections manager (like a super-Rewire), originated in Linux but now available in Windows and Mac also (the only missing feature in Musescore is full transport support). This way Musescore could be sync. with Audacity for audio, xjadeo/blender for video and Ardour/Mixbus for professional audio and midi DAW. All this software is available for the 3 operating systems mentioned.
In reply to Audio Synchronisation by pdro74
I think that's a completely separate thing. I can see valu Erin having synchronized audio in playback, and couldn't imagine wanting to install and run some totally separate program just to get this bit of simple functionality. Sure, implement more JACk stuff for people who need it for whatever reason, but don't require thos of us who just want a some audio to play wi our scores to need to use totally different software to get that result.