Now this one is TOO MUCH a whole CLEF appeared just after adding the last note in this screenshot. Nightly 4859
I would suggest developers shift focus to basic things working perfect and only after having THAT done move on to more fancier features...
Please developers, don't let an other MuseScore major upgrade happen exactly like the last one when version 1 came out and elementary features were not working properly.
I REALLY do appreciate the adding of so many good and useful extra features, but if basic things don't work, the whole project is only going to be ridiculed by commercial notation software fans, and, they would be right if they'd do so, because what good is a software that doesn't have basic things working as they should?
Thanks Daniel to be so passionate about MuseScore.
MuseScore nightly builds are for testing purpose only. So yes, there are bugs even in the most basic features because it's the way to enhance MuseScore : We need to break some features to add new ones and fix everything later. Nighly builds helps finding these issues, and let adventurous users taste the new features and give feedback on the implementation.
If you want to use and promote MuseScore, use the current stable version. MuseScore 1.1 is far from perfect but it works quite well.
Regarding your bug report, the title of issue is necessary to know what the issue is about when we scan the issue list. The appearance of key signature in the score while you are editing it, it's indeed a bug. So let's file a proper issue and close that one. Instruction to write good bug reports are here :
Freelinking: Unknown plugin indicator
Please excuse me, perhaps I didn't express myself well enough in the previous post.
When I asked the question "Why is issue title field required?" it was in regards to this very "Issue title" that is coming up with every other comment I make to a thread that I or someone else has already opened.
Are all of the issue titles tied together by code or something? I'm asking this because I remember that I gave this thread an initial other name, or, did you change it manually?
I thought that when I initially create a new thread, I give it ONE title then, and that stays.
That's why I wasn't getting the purpose of having an Issue title for every subsequent comment that is being made.
I am VERY passionate about MuseScore mainly because I don't have the money to buy Sibelius that is so expensive, neither do I want to raise money and spend it on it, it seems way to expensive to me.
And, in regards to the nightlies, I always use the latest nightly as I know that the newest nightly will be the MuseScore of tommorrow, so, if it's worth bug reporting, it's worth doing it on Nightlies.
You might remember me from a year or two ago, I used to be seseberg on musescore.org, I was always riding the cutting edge of development when I was writing scores, and I still am.
I believe that reporting a bug right when you see it is the best way to help a project advance, not to mention that a lot of things one only finds out as he's writing a very important score with intricate situations.
While I applaud your dedication to MS, I have also tried to use the nightlies for real work and gave up. They were far too unstable. I now only test them to see how the basic functions are coming along.
Also, your title of this topic and the first posting don't make sense. You're discussing a bug, but complaining about requiring a topic title. You have already started another issue about the subject title so keep that discussion there. Focus on the bug here.
The "Issue title" field is here to let users change the title of the issue because the problem might be different than the user first though or because the title is just inadequate. For example, the current title "Why is issue title field required?" is meaningless for this issue, the previous one "Preposterous bug" was also not very good, so I will change it.
I still think that this bug report should be closed and a new one, more to the point should be opened.
It's good to use the nightlies if you understand the development process a bit. Having a lot of bug reports is not really a goal per se. As a developer, I prefer having a good and detailed bug report than just two screenshots and one sentence. Quality over quantity if you prefer. I realize it takes time to make a good bug report, but it's often a lot quicker to fix a bug with a good bug report.
Indeed , a nightly build for a release that is probably still half a year away is bound to have lots of this not work. That just the nature of software development. Normally, we users never see those periods where basic functionality is broken, because the developers don't share those builds, byt every software proeject in the world goes through them. As they say, if you want to make an omelette, you've got to break some eggs.
As for 1.0, I don't remember any basic functionality being totally broken at all - it was quite a usable first release. Sure, there were bugs, but what 1.0 release hasn't had bugs?
shepers, something had to have happened to this thread, I don't remember giving it that senseless title, except of course if I wrote it being tired. I wrote something else here suggesting that after your post.
An other yet weird and peculiar thing that is occuring, when I browsed to this thread, the replies were not going "to the right" as they should in order to suggest proper replies and not appear as additional individual comments to the discussion, though on other ones I HAVE seen this happen. How is this possible then, I don't get it...
If I recall right, there were some GUI bugs, but I couldn't tell you what they were, it was a long time ago. I remember reporting some of them, but they weren't like critical basic issues, just pretty solid annoyances...
What good is good underlying code if the GUI is not usable? It's like looking at a dissasembled Porsche engine in front of you, you would kind of wish it could also "go" :D
Compromise isn't good for anything Marc, if software developers take on the attitude of "what 1.0 release hasn't had bugs" that can sometimes turn into a pretext of "leaving things as they are" and not keeping coding standards up.
Building software is like building a house, the foundation REALLY needs to be SOLID so that afterwards one can care less about it and work on cool additional features, otherwise one will always have to go back and fix the foundation thus wasting time and focus from whatever it is that they were working on...
Even these bugs that I have reported that I can't write one straight soprano line is SO utterly disheartening to me http://musescore.org/en/node/13220
Well, the "Preposterous bug" title was more of an expression of annoyance with this "pesky fly" of a bug... :D
So someone ELSE did change the title of this thread, I thought it was me being tired and not realising what I was doing :D
I do understand the development process, and I love the fact that I can report a bug here and it will be fixed by tommorow a lot of times (that's my good past pre-1.0 experience speaking here).
The thing is, the web development of this page is kind of not helping the users as well, I posted some feature requests and sent some e-mails via the contact form on how this could be improved.
While I do understand what you meant in your last 2 rows, I totally hate the "quality over quantity" thing, because quality is a primary notion while quantity is a measuring unit expression. To word it better, "One can have quantity without quality, but it's imposible to have quality without quantity" Having some kind of quality also implies a certain ammount of quantity, think of it in variables, you can have a 1-100 quality value attributed to a quantity value of 1, thus variable quality on the same quantity value. A bit off the subject here but relevant nontheless.
And even the web code differentiation between a "reply" and a "comment" desperately needs to be implemented if this website is to have any communicational coherence.
As schepers said in an other post, I also find it terribly hard to follow conversations a lot of times on here and need extra brain work to figure out what on earth is being said.
A "reply" should be a subsequent "text box" that keeps on going to the right as more happen, while a "comment" should be something independent of the "going to the right" thing.
In case you haven't gotten the point yet, the issue (bug) tracker is *not* for discussions. it is for a bug report, requests for info and notices of fixes. Keep the discussion in the forums and link to the bug report.
Also, separate the trunk (2.0) bugs from the branch (1.x) bugs by customizing the title with "[trunk] Rxxxx" where Rxxxx is the build revision. Otherwise when you go through the issue tracker you can't tell the difference between branch and trunk issues.
Comments
(Those key signatures just appear there out of nowhere after merely entering one note. WOW)
Now this one is TOO MUCH a whole CLEF appeared just after adding the last note in this screenshot. Nightly 4859
I would suggest developers shift focus to basic things working perfect and only after having THAT done move on to more fancier features...
Please developers, don't let an other MuseScore major upgrade happen exactly like the last one when version 1 came out and elementary features were not working properly.
I REALLY do appreciate the adding of so many good and useful extra features, but if basic things don't work, the whole project is only going to be ridiculed by commercial notation software fans, and, they would be right if they'd do so, because what good is a software that doesn't have basic things working as they should?
Now this is hilarious, after I posted my previous comment, I got this error that I attached in a screenshot.
Thanks Daniel to be so passionate about MuseScore.
MuseScore nightly builds are for testing purpose only. So yes, there are bugs even in the most basic features because it's the way to enhance MuseScore : We need to break some features to add new ones and fix everything later. Nighly builds helps finding these issues, and let adventurous users taste the new features and give feedback on the implementation.
If you want to use and promote MuseScore, use the current stable version. MuseScore 1.1 is far from perfect but it works quite well.
Regarding your bug report, the title of issue is necessary to know what the issue is about when we scan the issue list. The appearance of key signature in the score while you are editing it, it's indeed a bug. So let's file a proper issue and close that one. Instruction to write good bug reports are here :
Freelinking: Unknown plugin indicatorPlease excuse me, perhaps I didn't express myself well enough in the previous post.
When I asked the question "Why is issue title field required?" it was in regards to this very "Issue title" that is coming up with every other comment I make to a thread that I or someone else has already opened.
Are all of the issue titles tied together by code or something? I'm asking this because I remember that I gave this thread an initial other name, or, did you change it manually?
I thought that when I initially create a new thread, I give it ONE title then, and that stays.
That's why I wasn't getting the purpose of having an Issue title for every subsequent comment that is being made.
I am VERY passionate about MuseScore mainly because I don't have the money to buy Sibelius that is so expensive, neither do I want to raise money and spend it on it, it seems way to expensive to me.
And, in regards to the nightlies, I always use the latest nightly as I know that the newest nightly will be the MuseScore of tommorrow, so, if it's worth bug reporting, it's worth doing it on Nightlies.
You might remember me from a year or two ago, I used to be seseberg on musescore.org, I was always riding the cutting edge of development when I was writing scores, and I still am.
I believe that reporting a bug right when you see it is the best way to help a project advance, not to mention that a lot of things one only finds out as he's writing a very important score with intricate situations.
God bless MuseScore! :D :)
While I applaud your dedication to MS, I have also tried to use the nightlies for real work and gave up. They were far too unstable. I now only test them to see how the basic functions are coming along.
Also, your title of this topic and the first posting don't make sense. You're discussing a bug, but complaining about requiring a topic title. You have already started another issue about the subject title so keep that discussion there. Focus on the bug here.
The "Issue title" field is here to let users change the title of the issue because the problem might be different than the user first though or because the title is just inadequate. For example, the current title "Why is issue title field required?" is meaningless for this issue, the previous one "Preposterous bug" was also not very good, so I will change it.
I still think that this bug report should be closed and a new one, more to the point should be opened.
It's good to use the nightlies if you understand the development process a bit. Having a lot of bug reports is not really a goal per se. As a developer, I prefer having a good and detailed bug report than just two screenshots and one sentence. Quality over quantity if you prefer. I realize it takes time to make a good bug report, but it's often a lot quicker to fix a bug with a good bug report.
Indeed , a nightly build for a release that is probably still half a year away is bound to have lots of this not work. That just the nature of software development. Normally, we users never see those periods where basic functionality is broken, because the developers don't share those builds, byt every software proeject in the world goes through them. As they say, if you want to make an omelette, you've got to break some eggs.
As for 1.0, I don't remember any basic functionality being totally broken at all - it was quite a usable first release. Sure, there were bugs, but what 1.0 release hasn't had bugs?
shepers, something had to have happened to this thread, I don't remember giving it that senseless title, except of course if I wrote it being tired. I wrote something else here suggesting that after your post.
An other yet weird and peculiar thing that is occuring, when I browsed to this thread, the replies were not going "to the right" as they should in order to suggest proper replies and not appear as additional individual comments to the discussion, though on other ones I HAVE seen this happen. How is this possible then, I don't get it...
If I recall right, there were some GUI bugs, but I couldn't tell you what they were, it was a long time ago. I remember reporting some of them, but they weren't like critical basic issues, just pretty solid annoyances...
What good is good underlying code if the GUI is not usable? It's like looking at a dissasembled Porsche engine in front of you, you would kind of wish it could also "go" :D
Compromise isn't good for anything Marc, if software developers take on the attitude of "what 1.0 release hasn't had bugs" that can sometimes turn into a pretext of "leaving things as they are" and not keeping coding standards up.
Building software is like building a house, the foundation REALLY needs to be SOLID so that afterwards one can care less about it and work on cool additional features, otherwise one will always have to go back and fix the foundation thus wasting time and focus from whatever it is that they were working on...
Even these bugs that I have reported that I can't write one straight soprano line is SO utterly disheartening to me http://musescore.org/en/node/13220
The reply chain view is different in the "Issue Tracker" than in the normal forums. They are in linear date order, no indenting.
Well, the "Preposterous bug" title was more of an expression of annoyance with this "pesky fly" of a bug... :D
So someone ELSE did change the title of this thread, I thought it was me being tired and not realising what I was doing :D
I do understand the development process, and I love the fact that I can report a bug here and it will be fixed by tommorow a lot of times (that's my good past pre-1.0 experience speaking here).
The thing is, the web development of this page is kind of not helping the users as well, I posted some feature requests and sent some e-mails via the contact form on how this could be improved.
While I do understand what you meant in your last 2 rows, I totally hate the "quality over quantity" thing, because quality is a primary notion while quantity is a measuring unit expression. To word it better, "One can have quantity without quality, but it's imposible to have quality without quantity" Having some kind of quality also implies a certain ammount of quantity, think of it in variables, you can have a 1-100 quality value attributed to a quantity value of 1, thus variable quality on the same quantity value. A bit off the subject here but relevant nontheless.
Here are the website improvements that I suggested http://musescore.org/en/node/13221
And even the web code differentiation between a "reply" and a "comment" desperately needs to be implemented if this website is to have any communicational coherence.
As schepers said in an other post, I also find it terribly hard to follow conversations a lot of times on here and need extra brain work to figure out what on earth is being said.
A "reply" should be a subsequent "text box" that keeps on going to the right as more happen, while a "comment" should be something independent of the "going to the right" thing.
It's hard even to word this concept right, phew.
Well, it would be nice if they would have indenting, as it would be easier to follow through.
It's not all analytical in here, we're still communicating and we need a fluent way of doing that.
Not to mention the fact that we're not all experienced developers like lasconic and David Bolton and other guys around here. :)
In case you haven't gotten the point yet, the issue (bug) tracker is *not* for discussions. it is for a bug report, requests for info and notices of fixes. Keep the discussion in the forums and link to the bug report.
Also, separate the trunk (2.0) bugs from the branch (1.x) bugs by customizing the title with "[trunk] Rxxxx" where Rxxxx is the build revision. Otherwise when you go through the issue tracker you can't tell the difference between branch and trunk issues.
???
We will need exact steps to reproduce this bug. Feel free to open it again when these steps can be provided.
This is a duplicate of #13411: [Trunk] Courtesy clef appears in final bar after bars re-adjust. It's the same thing that Daniel was reporting, he just didn't explain it very well. This bug's been there for several revisions.
1. Create a new piano score, in Eb.
2. Drop a line break in the 4'th measure.
The resulting score will have multiple keysigs and clefs. Tested with nightly R4935
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.