v1.1 in Win7: General Observations
Nice product, overall...quite ambitious. Unfortunately, as is the case with just about all software on the planet, the development time and dollars have been spent on feature-functions and not on user interface and stability. Too bad...it's easy to tell that a lot of work has gone into this application.
Long story short, I spend a considerable amount of time 'chasing' this application all over my screen. Measures jump all over the place, dislodging alignment in previous work. The Save operation takes what I have meticulously worked on fixing and promptly ignores it or trashes it further. Interestingly, when saving to PDF, although I am offered the choice of replacing the existing file, it doesn't get replaced! The only thing I can do is actually delete the original file and saving a new one. There are a number of other problems similar to these, but the reader should be able to grasp the point. (See file attachments to this post for examples.)
Alignment of notes, measures, added text, lyrics, etc., is *extremely* fragile. One edit can throw everything all over the place as if it were dropped in a blender. Even something as innocuous as adding an accidental can result in such sudden destruction that sometimes even an Undo operation won't bring everything back as it was.
My message to your Development organization is the same tired plea that programmers have received for a quarter-century, yet seem to continuously ignore: get the architecture and interface right, PLEASE! - before you work on a single additional feature. What good is a set of robust features if the user cannot interact with the interface that presents and operates them?
| Attachment | Size |
|---|---|
| Muse1.jpg | 135.24 KB |
| Muse1-layout.jpg | 415.89 KB |
| Muse1-PDF.jpg | 186.11 KB |
Comments
It would help if you explain what you mean, but you might want to consider the possibilty the your problems stem from your inexperience with the program. Things *don't* just move around for no reason, so you probably aren't doing something correctly. It isn't clear from your screenshots what it is that MuseScore is doing that you would like it to do differently, so a better explanation of what you would want to accomplish would help.
In reply to It would help if you explain by Marc Sabatella
I think my comments and the screen shots speak for themselves. You can easily see the image in the PDF differs from its .mscz counterpart. Unless I was doing something devious just for laughs in this forum (which I assure you that I have better things to do), what I've showed you is obviously a problem. To make things even easier to see, I showed you the images within Musescore itself that show clearly that what I've fixed and saved in the workspace are not what Musescore 'sees' when displaying the layout. Even if I save what you see in the PDF image (which is how I want it), when I reopen the .mcsz file in the application, it shifts things right back to where they were before I fixed and saved.
How can I be doing something 'not correctly' simply by saving and re-opening? I can provide a number of other screenshots of missized fonts (even though they are shown as the same size in the Properties), Staff text labels which appear in different places when re-opening the file, etc. The point is that the application should not move or change anything unless I tell it to move or change it, and it's clear from the screen shots that it does.
In reply to I think my comments and the by greg.winters.10
Your problem is by far not as obvious as you seem to think it to be. I have to support Marc here, I too have not the slightest idea what your problem is.
Try this link to get to a better description of the problem, what you do, see and expect to see instead.
In reply to I think my comments and the by greg.winters.10
Your screen shots didn't show me much either and I've been using MS since Jan/11. You need to gain experience and read the forums for answers before jumping to conclusions and slagging MS. What you are likely experiencing is MS reformatting systems as you add notes and change measures. If you don't want this to happen, add some line breaks (palettes, breaks & spacers) about every 4 measures to spread the measures out better. This will generally format the systems with enough room in each measure to prevent the jumping as you add/change things.
In reply to Your screen shots didn't show by schepers
I guess I'm baffled by these replies. What is it about the comparison of the images that you don't understand? In Muse1-layout.jpg, I show the score as I composed it and intended it to look...in MuseScore. I have saved the file at this point, but left it open in the application. The text is simply highlighted and I selected the display in Layout so that you could see the differences right from within the application. How is it that you cannot see the differences?? In the Layout View, MS has brought an additional measure up into Line 2 of the score along with its Staff Text header "Chorus (1st Line Only)". In addition, the tablature markings that I've aligned under the notes have been scattered.
It took me a few tries to get to the position where I could save a PDF of the alignment the way I wanted it (Muse1-PDF.jpg) because MS would save what you see in Layout View in the PDF, not what you see in the normal view. When I would examine the PDF, it would look just like what you see in Layout View, but for some odd reason, on the third or fourth try, I got the PDF the way I wanted it even though I did nothing but consistently re-align the notation and Save As.
Muse1.jpg was the image I captured *immediately* after I had created the good PDF file and closed the application. I repeat: I did absolutely nothing in the application after saving the PDF or closing the application. Nothing. When I reopened the application, I captured the image and the differences between what was displayed on my screen and what was in the PDF are obvious. Furthermore...when I saved the file that you see in Muse1.jpg as a fresh PDF, the PDF displayed - again - what you see in Muse1.jpg with everything - again - misaligned!
You can see this is not a matter of display incompatibility where the application is simply showing the user one thing and doing another (with the exception of the contradiction shown in Muse1-layout.jpg). What 'experience' does the user have to gain here?
Besides, the burden if WYSIWYG should not be upon the user. The user should be able to trust that what is displayed on the screen and has been saved is what MS will faithfully reproduce when called upon again, either to print or reopen the file.
For example, trained musicians know that layout is an extremely important aspect of reading music. There is a reason why, for example, I wished each line in my score to have exactly four bars: that's how the phrasing goes. Here's where I will deviate slightly from my 'PDF is how I want it' remark since it reveals a different issue that I didn't directly bring up here previously. Notice in Muse1-PDF.jpg that there are five measures in Line 3 and only 3 measures in Line 4. Why? Well, try for the life of me, I tried to get 4 bars per line, but finally gave up. I used the SHIFT+{ and SHIFT+} tools until I was blue in the face. I used them on one measure...I used them on multiple measures...I even tried using them on just a few notes. Although they did indeed 'push' and 'pull' the notation back and forth, I could never get them to give me exactly four measures per line the way you can see they are for Lines 1 & 2.
This nightmare goes beyond 'experience' - the application should not be jumping around like this in the first place. Autosizing is fine, but when one stroke of the manual sizing tools causes everything to blast apart, then the concept is lost. I searched in vain in the Help systems - local handbook and online - and could find nothing talking about this behavior and the inconsistencies I've shown here. 'Autosize,' 'autosizing,' 'measure size,' 'jumping,' etc. And when I searched for 'Stretch' (as is the word used by the tools), all I get is another one of those useless "You can do..." Microsoft-style 'help' statements that tells me absolutely nothing as to how the tool works, best practices for using it, etc. (I noted similar discussions in the online forums with equally baffled users, so I'm not alone here.)
The upshot is that it's bad enough that the user spends most of his/her time battling with the interface, but at least this is doable. It's a showstopper, however, when even MS itself can't 'see' or 'remember' what the user has done and when it comes time to print, or save/re-open and the layout is trashed.
In reply to Look at images by greg.winters.10
Once again, add line breaks. If you don't see why or how they work, read the manual. When you add them, this measure "jumping" won't (usually) happen. MS makes no assumptions about how you want the layout to look, so when you have it how you want, add the line breaks to fix it in place.
And yes, experience with the app will do wonders. Stop jumping to assumptions about how things work in MS and get used to it, read the forums, etc.
In reply to Once again, add line breaks. by schepers
Have you read what the Help manual says about Line Breaks? Where is the 'why' part of the explanation that you claim is there? Your response addresses nothing about the issues I raised, nor is there anything in the Line Breaks section (or anywhere else, for that matter) of the manual which does, either:
1. Why does MS display one layout and save another?
2. Why does MS display one layout in one view and display it as a different view in another?
3. Why is there nothing in the Help system describing how the autosizing works and what the user can do to manage it? (Where is your suggestion in the Help manual to use Line Breaks to control jumping? In all desktop publishing and word processing applications, Line Breaks are used for the express purpose of creating *new* lines, not to control the layout of the existing lines. Since there is no guidance in the Help manual, how would the user ever know to use this tool in such an unorthodox way?)
4. Why is there no explanation as to how the Stretch tools work?
Anything that is not WYSIWYG should have full disclosure in a Help system. Yes, Line Breaks do seem to control the behavior of the score layout, but now whatever they are doing as part of their normal section control function, the user has to deal with the drawbacks of this separately. A user should never be forced to use a tool for something it was not originally designed for: Line Breaks are for creating new lines, not for controlling the horizontal and vertical behavior of the layout. But even if my opinion about Line Breaks is flawed, there is still nothing in the manual about the aforementioned issues.
In reply to Help Manual by greg.winters.10
MS is not wysiwyg, therefore your assumptions about how it should work are flawed. It is also not a word processor or a page layout prg, all of which I am also very familiar with. There is no way to have wysiwyg music layout as too many things will affect the layout of the notes, measure widths, system layout, etc. Notation layout is very fluid as you are finding out. No music program I have used over the past 18 years has been that way.
Since MS is open-source, and subject to rapid changes and updates, all aspects including help and online manuals are up to everyone to update and support, as many people try to do. It is not up to just the limited development team to look after all aspects. The manuals can become very stale or wrong quickly. If you find a deficiency either calmly and politely point it out or you can fix it yourself.
Have you tried using line breaks yet, maybe every 4-5 measures? You will see how they are useful.
In reply to MS is not wysiwyg, therefore by schepers
Well, this is certainly a disappointing response, but at least it addresses the issues I listed, so I appreciate it nonetheless. What you're saying, in effect, is that MS simply displays the compositions linearly and is not really set up for a user to *read* the work, like a piece of sheet music. What seems to be important in MS is just the composition itself and the notes as they relate to one another between the staves. I can accept this, I guess.
I would have to disagree with your lumping of all 'music programs' into this description, however. I've used both Finale and Sibelius a number of times and they both provide tools for quite the precise layout with the performing musician in mind. Granted, these applications cost money and as you note, MS is open-source, so it's an apples-to-oranges comparison. (I would gladly pay for MS if it was more layout-friendly.)
I would also have to disagree with your assertion that WYSIWYG is too arbitrary for the application to deal with. As I mentioned in a previous post here, I can deal with the idiosyncrasies of maneuvering the objects around in light of the very reasons you cite, but my issue is: if I *have* arranged everything precisely the way I want it after all this effort, then why can't MS save/print the layout as I see on the screen? My canvas is 8.5x11 - just like the paper and PDF boundaries. What is so 'complicated' about having the application simply imitate what is on the screen?
I use MS primarily to compose parts for other members of my bands to read and learn, and I love the playback function which allows them to hear the parts, as well. When the layout is not in typical style, then this makes their jobs harder, that's all. What is the purpose of displaying something to the user one way on a computer screen and an entirely different way on paper? There's an infinite number of ways something can vary from what a user sees, but only one way it can match.
In reply to WYSIWYG by greg.winters.10
"I would also have to disagree with your assertion that WYSIWYG is too arbitrary for the application to deal with. As I mentioned in a previous post here, I can deal with the idiosyncrasies of maneuvering the objects around in light of the very reasons you cite, but my issue is: if I *have* arranged everything precisely the way I want it after all this effort, then why can't MS save/print the layout as I see on the screen? My canvas is 8.5x11 - just like the paper and PDF boundaries. What is so 'complicated' about having the application simply imitate what is on the screen?"
Without knowing the insides of MS (which I don't) I suspect it's related to the way MS is setup to compress measures very tightly until you change the stretch (compression) or set manual line/page breaks. This seems to push each system to the very edge of one measure jumping to another system. This compression is very evident when you create a new score and there is about 15 measures per line. Things are very tight.
What's even more annoying is when you create a score and forget to change the page type from the default A4 to Letter. You fully lay out your score, then try to print and realize somethings wrong, change the page size and have to manually change things again. This is also somewhat alleviated through proper use of breaks.
In reply to Look at images by greg.winters.10
>What is it about the comparison of the images that you don't understand? In Muse1-layout.jpg, I show the score
> as I composed it and intended it to look...in MuseScore.
Well, for one thing, that's the kind of information you left out of your original post. We literally had no idea what the imahes were supposed to represent. We could see there were differences in the pictures, but how we we supposed to know what the pictures were trying to show or what you did differently to create one images versus another? Your followup above that finally adds this infomation helps, but it still isn't completely clear. Better would be to post an actual MSCZ file and steps to reproduce whatever it is that you see as a problem. I've never seen it it do anything like what you seem to now be describing in terms of showing one layout in one situation but another in abother situation, so instructions on how to actually reproduce the problem you that you (and apparently only you) are seeing would be most helpful. Certainly, it is possible that there is some sort of bug that you are encountering but the rest of don,t for some reaspn - but again, a sample score with specific instructions to reproduce would be necessary in order for us to see it.
But in any case, think of layout as being like in a word processor, with word wrap that cuts in to decide how much to fit on each line, and when you add more material or make any other changes whatsoever, that can indeed throw off the results, just as it does in a word processor. That's what the manual breaks are for. If you need your line breaks to occur in specifical places, as opposed to being happy with whatever MuseScore decides at any given moment, then you add line breaks - again, just like a word processor. And adding them is trivially easy - select the bar line, hit Enter. Yes, it's important, and that's why it is simple. Adding line breaks every four bars is as simple as selecting those bar lines and hitting enter - or using the "break every X measures" plugin. So again, I'd say your problem stems only from your lack of experience with the program.
There is no denying it takes a little while to get accustomed to how things work, and of course, better documentation would help. Since this is open source, feel free to offer to contribute to that effort, but realize that all official documentation needs to be translated into dozens of languages, which is whiy it tends tends to be a bit spare. So tutorial vidos - especially ones that require no captions or narration - tend to be especially useful.
In reply to >What is it about the by Marc Sabatella
In my original post, I submitted the image files with details as to how they were arrived at. However, even if I had not done this, you can easily see by the Muse1-layout.jpg image that there is a problem. This requires no explanation whatsoever. You can see that (unless I've doctored the image, which I haven't) that the Layout Page Settings dialog exists side-by-side with the composition in the workspace. It has to. It can display nothing else. From there, you have to ask yourself a fundamental question that has nothing at all to do with 'user experience': how can the layout be displaying something contrary to what is showing in the workspace? Period.
I can show you a number of other compositions I've created where the Layout/Page Settings display matches perfectly with what is in the active workspace. It's no coincidence that when I've saved *these* files, there has been no 're-shuffling' of the display upon re-opening, nor has there been a problem with the PDFs. The problems I've listed occur in roughly 50% of the cases I work with.
I'm not the 'only one' who is experiencing problems with this autosizing and jumping. Here is but one of the items I've seen in your blogs: http://musescore.org/en/node/13399.
I've done what you've asked me to do and attached files to this post. I'm providing just a tiny example so there isn't a lot of complexity for you to wade through. The steps are not complex, either: 1) I composed the original work and manipulated it so it appeared in the active workspace as you see in the attached PDF - everything aligned just like that. 2) The PDF file is what I got when I saved the .mcsz file in PDF format (after a number of tries). 3) The .mcsz file is what it still looks like when I re-open it no matter how many times I fix it to look like the PDF file. If you can find anything out as to what I'm doing 'wrong,' then I would appreciate it. Thanks.
According to the front page , MuseScore is WYSIWYG.
In reply to According to the front page, by chen lung
...which is why I submitted the original post.
In reply to Exactly... by greg.winters.10
Maybe its wysiwyg once you fix the final layout, but not while you enter notes and add elements, load.save. Sometimes I just have to drag an element (some form of text) unrelated to any note placement and a few measures will respace unexpectedly. Once you learn this, you also lrean how to make things work.
Wysiwyg is a very overused term which came into vogue with the advent of computerized page layout and word processing. I've had MS shift around measures between a save one day and reload the next, esp before I started to use breaks. This is why line breaks, page breaks, stave spacing, etc are important to the wysiwyg nature of MS.
In reply to Maybe its wysiwyg once you by schepers
If you want to see non WYSIWYG, see lilypond or ABC - both are plain text formats that are then "compiled" to give you the graphics. In that most basic sense, MuseScore is totally WYSIWYG. But the real distinction is between a word processing style, where as you enter text, you don't necssarily know or care where on the page it actually ends up, versus a desktop publishing style, where elements never move once placed.
So back to the specific issue being discussed - sure, if the score looks a particular way, you should expect it to look the same when saving to PDF, and it should look the same on save and re-load. But every so often, small discrepancies arise that might happen to push a measure onto the next or previous line - just as happens with word processors on occasion. For imstamce, roundoff errors in the margin size calculations or whatever could conceivably do this if you happened to be right on the edge. Seems once in a blue moon I see something like that; perhaps the OP just haened to run into one of those rare situations roght pff the bat. But on any case, Again, if you care about the specifics of layout - as we often do - you use the specific controls provided for that purpose: line breaks. Insert one at the end of every line, then maybe reduce stretch pne notch to be sure you aren't right one the edge of one of those roundoff differences. Easy as pie.
In reply to If you want to see non by Marc Sabatella
I will add that page formatting in MuseScore is a pain in the arse until you get used to the way it works.
I am about to create a series of tutorial videos on this very subject, as a lot of it appears extrememly arcane until you have fathomed what all the options do - Page Fill Threshold and Last System FIll Threshold are both extremely germane to some of the problems you have mentioned, and until you understand what they do, you are liable to throw something through your monitor in frustration.
My suggestion is that you play with these parameters and see the effect they have on your score - sadly I don't have time tonight to expound further.
I'm not experienced enough to comment on the specifics of your question. They may be valid, they may not, but the tone of your message is a little harsh. MuseScore is free, and as such is never really going to be a direct competitor to the likes of Sibelius etc. However, for the majority (myself included) it is a fantastic piece of software once you get used to the way it works. Remember the out-cry when MS introduced the "Ribbon toolbar" for Office? Once you make friends with it, life becomes easier, but it does take time.
Why don't you separate your ideas into feature requests and post them in the appropriate forum where they can be discussed, refined, and potentially implemented?
What MuseScore really does have going for it, is a fantastic support base on these forums.
In reply to I'm not experienced enough to by essdeeay
I'll admit that my original post may have seemed 'a little harsh,' but this was after many frustrating attempts to get the application to perform what I had thought should be simple, common sense tasks. I work in the world of software and computer technology on behalf of business customers, and can tell you that after a lengthy period of curiosity and free passes, the chickens are coming home to roost on the notion of "technology for technology's sake."
Note that I wasn't complaining about the usual things you see in these support forums - something that a particular user would like to see the application do for his/her personal needs. I recognize that there are many ways to use software, and that human imagination is a powerful tool. No, my issues had to do with the apparent abandoning of well-established principles of human interaction with machines as well as centuries of traditional style in musical composition - two concepts which have been largely tossed out the window by most developers of software.
You mention the ribbon toolbar for MS Office and the controversy it caused - a good example. The issue was not the features of the new tool as much as it was - yet again - another wholesale dumping of something that millions of people had painstakingly learned how to use in favor of a new device which is hardly intuitive to use (can you tell me why Page Breaks are on one ribbon and Section Breaks are on another?). This is done in the name of 'improvement,' yet in another few years, the ribbon bar will be dumped for something else, and we'll have to begin our learning curves all over again.
The vast majority of computer software users do not wish to become computer geeks, dedicating their lifelong pursuits to grasping rudimentary functions of the tools. Instead, we wish to learn the tools, then get on with using them to produce real-world experiences Can you imagine if the vehicle you drive were like a typical software application? The brake pedal used to be to the right of the accelerator, now it's to the left. The knob that used to turn on the radio now activates the wipers. Etc.
Intuitive use of software is based upon the premise that the user can trust what s/he sees occurring before his/her very eyes (WYSIWYG). Linear decision-making is wholly based upon this faith. For example, back in the day, Word Perfect could run rings around MS Word as a word processor, but even when it became GUI-based, it's developers refused to abandon the premise that the end user should become a programmer in order to use the application 'properly.' MS Word was more user-friendly in regard to the GUI, and in just a couple of years, wiped Word Perfect off the map.
In the case of MuseScore, my supposition - now demonstrated to be in error by the replies I received here - was that the application provides me a canvas where I can use this wonderful set of 'writing' tools to create a computer-based sheet music product -AND- that the decisions I make for placing of the objects and layout can be wholly based upon what I see on the screen before me.
And why shouldn't that have been my belief? Look at all the various ways that MuseScore leads one to this conclusion. For example, what exactly *is* a 'page setting' if it isn't for...laying out pages? Well, 'pages' of *what*? And look at all the tools available which are designed to control sizing and behavior of the objects as you build your work.
My objection (and related 'harshness' of my critique) was that it seemed that the developers had either forgotten about the fundamentals of music composition layout from the days of staff paper, or had deliberately abandoned them. For example, music that employs more than one staff usually requires vertical alignment between the measures. Thus, the user expects that when the sheet is 'ruled,' i.e., the bar lines are carefully placed in order to accommodate the planned music, then what is subsequently composed will not seriously impact this layout, and if movement of the measures is required, then the changes will be subtle and easily manageable (Line Breaks are a coarse, arbitrary means of doing this). In the case of MuseScore, I've had music shift backwards and forwards simply by adding an accidental! Tell me anyone who has ever had to re-rule their composition because of adding an accidental.
Another example: wouldn't one think that when it comes to music composition that a strong feature of the application would be support for standard printing? Well, not only is there no Print Preview (something which has been standard for years in applications where printing is important), but I've had numerous cases where what I see on the screen - on an alleged 8.5x11 canvas with meticulous margin and spacing settings pre-set by me - has come out wholly differently on the printed paper: titles chopped off, measures re-arranged, etc. Sometimes the printouts have been perfect.
My point to all this is that far too much time and effort is spent on features and not standardization of architecture and platform. This is akin to providing an 8-speaker 400w stereo for your car, but when you turn the ignition key, it won't start. Examples of lack of attention to architecture in MuseScore include: 1) Why are some composition objects (e.g., bar lines, accidentals) double-clicked to add while others must be dragged? 2) Why does the Paste option show active in the popup menu, but won't paste when the option is selected in some cases? 3) Why does it matter on the score where you want to place something in order to get it to work (e.g., you can't add a repeats bar line to the beginning of a staff)?
When I have submitted architecture and UI inconsistency issues to developers in the past, they have been largely ignored. The answers I've received back from them (which are rare) have to do with a general public still besotted with feature addiction and that core function improvements aren't sexy enough to give attention to. I didn't know until now that MS is open source, so that explains a lot of it, but before we consider providing things such as user-defined slur directions and same-instrument polyphony, we should work on standardizing the interface to WYSIWYG and placing the burden of effort upon the user who wants to 'have' something different than s/he sees on the screen.
My feature improvement request: standardize the UI.
In reply to Feature Fatigue by greg.winters.10
I agree with you (esp. about accidentals etc. shifting the layout), and working out what does what is complicated, especially for a first-time user of Musescore, like myself. Even when you're in the right portion of the GUI there are a lot of options that aren't obvious what they do, like in the edit-style sections.
I imagine the rules for layout of music are much more complicated than those of a typical word-processing document, but that doesn't prevent there being a coherent set of sensible rules, including those for formatting. For example, should the space a particular note occupies, also include a space for an accidental if required? Are there any other standard objects that should be included in this space? And the same goes for other objects... should there be a reserved space for modifiers?
I assume there are some industry-standard rules for things like this? If not, why not copy the rules applied by other leading software in the market? Even lots of the keyboard shortcuts are the same as in Sibelius (although, annoyingly, the numbers to designate note value during note entry are not the same).
I know nothing of the development team, numbers or expertise so may be speaking out of line here, but could this be the right time (with enough community help/discussion) to re-think certain aspects for version 2? I'll certainly involve myself in GUI-design and layout discussion.
Steve :)
In reply to Let's make it happen! by essdeeay
Just opened a discussion thread on UI issues here:-
http://musescore.org/en/node/14205#comment-49039
It's probably too late to get anything into Version 2 at this stage, as I think feature freeze is already in place.
In reply to Feature Fatigue by greg.winters.10
I think at this point, you're speaking way too generally to be useful. It would be better to talk *specific* issues you are having - and each such issue in its own thread. You are seeing this as an overall systemic issue, and as a newbie, I can see how it might seem that way, but really, the few hints of specifics you have given make it clear there is a smattering of simple user misunderstandings, potential small bugs in the software, and perhaps a place or two where either UI or documentation could be improved to make something more clear. Each of these needs to be dealt with individually, so again, I'd suggest starting separate threads. And st oeast consider he possibily in any such hat thread that difficulty you are having will turn out to be a very simple misunderstanding.
As far as the overall big picture, I explained previously, MuseScore *is* WYSIWYG, but that doesn't mean that just because you enter a symbol and it happens to be at the end of a line when you enter it, that it will always stya in that same physical position on the page. As soon as you make the connection to a word processor with word wrap, and if you want to fix the position of things to make them immune from word wrap you need to do so as a separate explicit step, things start to seem a lot less surprising. Something to keep in mind as you start your new threads discussing specific issues.
Also, you need to keep in mind that MuseScore did not invent the category of software to which it belongs. Virtually all other popular notation programs do things very similarly in these respects, so in the sense of minimizng user surprise, meetng the expectations of the millions of users of other programs is more mportant than you seem to be considering. MuseScore's interface is based n very large part on that of the single most popular notation program in the world (Sibelius). And the popularity of Sibelius over the former #1 - Finale - is based almost entirely on the perception that Sinelius is the easier to use of the two (Inale is perceived as the more powerful). The fact that many users will come to MuseScore with some pretty specific expectations based on Sibelius or Finale is something else you need to keep in mind as you think aout possible novel and unfamiliar ways MuseScore could have been designed.
In reply to I think at this point, you're by Marc Sabatella
OK...Start and End repeats. For End repeats, you have to carefully select the bar line of the last measure in the section to be repeated and double-click the End Repeat object. Works great. Not a problem. For Start repeats which are to be located at the beginning of a line, one would intuitively believe that the same process would occur: select the bar line, double-click on the Start Repeat object, and you're done. Not so.
First of all, you can't even select the beginning line of a staff - it's simply 'dead.' This leads you to believe that you have to select something else in order to insert the Start Repeat. The first inclination is that since a bar line is a measure divider and repeats are located where bar lines are normally located, then one would have to select a measure, then double-click the Start Repeat object and we should be good.
Well, not quite. When you select the entire first bar and double-click on the Start Repeat object, then you not only get a Start Repeat at the beginning of the first bar, but you also get a Start Repeat at the beginning of the *second* bar. (Why this is a default condition of this feature I can't figure out.) OK, that didn't work. Next thing I tried was selecting a note or rest at the beginning of the first measure, and - bingo! - I got my Start Repeat located properly. (Or, somehow you would have to infer that the *end* barline of the previous measure is actually the *start* barline of the next even if those measures are located in different staves.) Here's where the discussion comes to the point...
There is nothing in the Help system that I was able to find that specifically addresses how to easily add Start and End repeats. To add to the confusion, there is a Repeats palette that specifically deals with other types of repeats, but Start and End repeats are considered 'barlines' in MuseScore. When I searched on terms such as 'start repeat' and 'barline,' I got nothing. It was by sheer accident that when I searched on repeats that even though I did not find anything about Start and End repeats in the manual, I noticed a line that indicated that a repeat should be *dragged* to the measure in question (as opposed to double-clicked?), and when I tried this with the barlines, it worked perfectly.
From a composer's point of view (not a 'Sibelius' user), I'm left trying to figure out why in the first context, the Start and End repeats are considered 'barlines,' but when it comes time to using the Start Repeat, it's not the same type of barline that the End Repeat is, i.e., it requires a different editing practice in order to implement.
There are many other examples of this inconsistency that I could provide, such as: why can I double-click to insert a slur and not a volta? But my point is not to argue for one or another or for another feature to be created. It's actually to demonstrate that the very concept you're saying is 'too general' is actually quite specific: standardize the use of the tools as they fit into traditional music composition.
In the slur vs. volte case, there is no such difference in layout usage that you've inferred could be the cause behind the operation variance: with both, you select an insertion point (as is the case with nearly everything about composition, really), and you expect the tool to 'see' where that is and act accordingly. The tool is guided by either a single point ( wherein the user would edit the object once it's in place), or by providing a shift-click 'range select' whereby the object would 'spread itself out' over the area selected, if appropriate. In our example here, if I've range-selected a number of measures, then attempted to insert a volta, then it just comes in at random, completely ignoring my original range-select action. (This gets even more complicated when attempting to create a volta that crosses lines. Musically, there is nothing inappropriate about my desire to extend the volta across lines - this is done all the time in music. Yet, the tool ignores my intention.)
You seem to think that this is an issue of enhancing the functionality of the volta tool. In many respects it is. My point is that music composition techniques as well as de facto (Windows) GUI practices provide a set of general usage requirements that *all* features developed for the application should adhere to: copy & paste, scrolling, multiple and range select, drag & drop, etc. Thus, no tool would be introduced into the set that does not already strictly conform to this consistency of appearance and use. Whatever its new or enhanced functionality, it would never abandon or contradict these base standards.
Furthermore, if you want to call some of these things 'bugs,' then I would agree only insofar as they fail to adhere to these fundamental standards. I would not agree that the blame lies solely with the feature itself and that it somehow is 'malfunctioning.' Anything that is not designed to function a certain way in the first place cannot be counted on to actually be built to do so. I see enough of these architecture inconsistencies in MS to believe that there is little attention paid to them right from the beginning.
As I mentioned, this is a widespread condition of software development - will we ever be able to smooth-scroll in MS Excel?? MuseScore is an incredible accomplishment. I wouldn't bother with this kind of critique on a piece of junk. I appreciate all the hard work that has gone into it and will continue to use it.
In reply to Something specific... by greg.winters.10
Everything about barline styles is for right barlines only. Could have been implemented differently, I suppose, but here is a place where I'd say just a slight tweak to the documentation to make the process clearer is all that is needed.
As for the other things you mention, once again, I would strongly urge you to start *individual threads*, one issue per thread, for them. Otherwise we get this big sprwaling unfocused discussion that is very difficult to follow. Some things you are talking about are outright bug reports (like whatever is happening to make your print look different from what is on screen - something I've enevr seen or heard of before). Some of it is simple user misunderstanding. Some of it is places where a tweak to the socumentation would help. Some of it is places where a slight change to the UI might make most sense. Again, separate thrads for separate issues is much much much more helpful than an unfocused thread like this.
In reply to Something specific... by greg.winters.10
To add a volta spanning several measures, double click the volta and use Shift + right arrow. See Volta .
I understand some of your concern about usability. A software can always be made more usable. I disagree that MuseScore is not consistent in his current interface and that we don't pay attention while implementing... Select something and double click to add it. If there is nothing (like for a start repeat bar, there is no barline at the beginning of a system, after the key signature), use drag and drop.
I strongly agree with others in this thread... The best way to help improving MuseScore is to create bug reports or feature requests targetted enough. Entering lines (Volta, pedal etc...) by selecting a range and double clicking is a nice feature request that could be elaborated and submitted to the issue tracker. Even better, you could code it and submit a patch if you have the ability.
In reply to Feature Fatigue by greg.winters.10
You wrote:
> 1) Why are some composition objects (e.g., bar lines, accidentals) double-clicked to add while others must be dragged?
I suspect the technical reason is that dragging is always an option, but some elements are attached to other specific elements and hence can optionally be placed by double clicking after first selectng the item to which it will ne attached, and other elements are not attached to any other specific element. But ndeed, there is room for improvement here, and a separate thread on this topic alone would be beneficial.
> 2) Why does the Paste option show active in the popup menu, but won't paste when the option is selected in some cases?
A good example of a case where we'd need a *specific* example in order to know what you mean. That is,ost a score and a series of steps to follow so others can reproduce what you are seeing. But anyhow, the most likely will turn out to be, a simple bug to report as such.
> 3) Why does it matter on the score where you want to place something in order to get it to work (e.g.,
> you can't add a repeats bar line to the beginning of a staff)?
Not sure what you mean by that. What is stopping you from adding a repeat to the beginnng of a staff? How are you trying to do it? I add repeats to the beginnings of my staves all the time; in fact I rarely add start repeat symbols anywhere else.
> In the case of MuseScore, I've had music shift backwards and forwards simply by adding an accidental! Tell me anyone who has ever had to re-rule their composition because of adding an accidental.
Here's where you need to keep the word processor analogy in mind. If you add one character to a line, yes indeed, it is perfectly normal and to be expected that this might sometimes have a ripple effect through the rest of the paragraph in terms of where the line breaks turn out to be, and that this might in turn have a riipple effect through the document in terms of where the page breaks turn put to be. That's an every day occurenc in every word processor, because word wrap is just. And the same for MuseScore's "measure wrap". A program that ignored your carefully crafter spacing settings and just let you cram more symbols onto a line *without* trigger the measure wrap that your layout settings tell MuseScore to hmor would be broken.
Regarding the original post, it looks like one or several bugs. MuseScore should be WYSIWYG, if you can demonstrate otherwise, it's a bug and it needs to be fixed. To fixed, we need to be able to reproduce.
So can you provide a simple score in MSCZ format that demonstrate the "measure jump" after reload bug? Or a set of steps to reproduce the problem? preferably in a new forum post, together with the MuseScore version and your OS.
Regarding saving PDF, I can't reproduce this problem. Can you provide precise steps to reproduce from a blank MuseScore? Idem, in a new post.
What good is a set of robust features if the user cannot interact with the interface that presents and operates them?
http://en.wikipedia.org/wiki/Release_early,_release_often (We don't release as often as we would like... but we do our best as a small team)
In reply to Regarding the original post, by [DELETED] 5
OK...I'm going to start listing these things out separately. I still say that despite 'open source,' the issues are all common to the interface as well as including enhancements and/or 'bug' fixes. You'll see from the screen caps that accompany the files that this stuff is all over the place, and if anyone can figure out what I'm doing wrong, I'll appreciate it. Thanks for all the responses.
In reply to Separate Threads by greg.winters.10
Maybe add them to the thread I opened General UI issues.
http://musescore.org/en/node/14205#comment-49039
If we can get all these things collated in one place, it will be that much easier to open something in the Issue Tracker for fixing in a future release.
Just make sure each one is in a separate comment - you will see I have already mentioned one of your issues.