I have started to look at contributing to musescore development after having used version 1.2 for drum set notation so successfully.
I'm trying to get a feel as to what state trunk is in compared to 1.2 and I can see that there are various regressions concerning drum notation specifically.
Irrespective of whether the note stem direction is up or down in the edit drumset dialog, the stems always points up. Not only that but when the down stem direction is selected in the drum set dialog, the stem simply moves a few pixels to the left but remains in the up direction.
Not specifically drum set related, there seems to be a general UI issue on the mac. In general the text seems to be either too big or is truncated in various places and the general feel on the mac is that the ui is a bit squashed compared to the linux version.
Some graphics are missing on the mac for example the left hand graphic in the create new score wizard is missing but is there in the linux version.
The icon size edit box seems to be squashed in the create new score wizard as shown in the screenshot below.
Is this a known cross platform issue with Qt? What needs to be done to keep the ui consistent between platforms?
Sound on the mac suffers from clicks almost as if the audio buffer is not being filled up in time but seems ok on linux for the same build.
At the moment I can't use the trunk build to do any drum set notation due to it's current state, whereas version 1.2 was pretty flawless. Are these regressions known about and have they been assigned an owner or have they slipped in with nobody noticing due to some other architectural changes? I wanted to try and fix some minor bugs I had noticed in version 1.2 but am finding it hard to even get a basic drum score going in the latest trunk version and therefore finding it hard to get a handle on where to start with this version.
Thanks Chen, I should have checked the issue tracker I suppose.
I'm trying to get a feel as to how the musescore project is run. Are there specific owners of certain areas of the code base? Who reviews commits before submitting? Are there any regression tests? I assume some previous commit must have broken the drumset stem direction. I could investigate to see if I can fix it but this commit may have been part of some ongoing architectural work to do with drum set notation in general and it may be the intention to fix it up in further commits. How can I find out this type of information, is it documented anywhere?
I just feel a bit unsure where to start with my potential contribution to musescore without knowing if the work I might embark on is already being covered by someone else.
80-90% of the development is made by Werner Schweer so in the end, he
is the one to decide what goes in the SVN. We are a couple to have
write access to the SVN and we try to use it responsibly.
Leon Vinken is mainly working on MusicXML import/export. Miwarre is
dealing with everything tablature related. I try to have a global
picture and I commit mainly bug fixes, or UI related stuff. I try to
commit patches made by others as well to take a little bit the burden
off Werner's shoulders. If I'm not sure I share it with Werner via the
issue tracker. So if you have any contribution, open a bug or assign
yourself an existing one and post a patch, I will review it, talk with
Werner if necessary, and commit it.
We have a couple of regression tests. It's very recent and a work in
progress. You can check the mtest directory.
There have been a major rewrite of the stem and beam code by Werner
during the last weeks. I suspect the stem direction of drum notes in
palette is a side effect of it.
The best way to know if you are walking on someone territory, it's to
communicate and above all, to write code! You might end up doing
double work, but if you communicated, it will be rare and even if you
do double work, you'll have learn something more about the code in the
process. And there is a lot to learn in MuseScore codebase :)
Last point, regarding Mac specific issues. I'm the release manager for
Mac but I have limited time to deal with specific problem on this
platform. Moreover, any change might impact the other platforms... In
any case, if you see room for improvements on Mac, again, go ahead,
submit patches !
> Thanks Chen, I should have checked the issue tracker I suppose.
> I'm trying to get a feel as to how the musescore project is run. Are there
> specific owners of certain areas of the code base? Who reviews commits
> before submitting? Are there any regression tests? I assume some previous
> commit must have broken the drumset stem direction. I could investigate to
> see if I can fix it but this commit may have been part of some ongoing
> architectural work to do with drum set notation in general and it may be the
> intention to fix it up in further commits. How can I find out this type of
> information, is it documented anywhere?
> I just feel a bit unsure where to start with my potential contribution to
> musescore without knowing if the work I might embark on is already being
> covered by someone else.
> View this message in context: http://musescore-developer.685061.n2.nabble.com/Drumset-notation-seems-to-be-broken-in-trunk-tp7548283p7548416.html > Sent from the MuseScore Developer mailing list archive at Nabble.com.
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________
> Mscore-developer mailing list
> [hidden email] > https://lists.sourceforge.net/lists/listinfo/mscore-developer