Save & Reopen
Here's just a small example of the Save/Reopen issues I'm having. For some scores, the reopening is faithful to the Save. For others, such as the attached, it's a crapshoot. Note the arbitrary repositioning of 'Last Choruses' in this screen cap set as well as the moving of measures on Page 3. Again, I maintain that there is absolutely no excuse for this to ever happen. The application should never decide on its own how it thinks the display should be if the user has designated otherwise.
| Attachment | Size |
|---|---|
| He Was There All The Time (K-Synth).mscz | 4.64 KB |
| AsReopened.jpg | 389.74 KB |
| AsSaved.jpg | 385.17 KB |
Comments
I suspect this is one of those cass where as I suggested earlier, you were right at the limit of whether that measure to which "last chorus" was attached would fit on the system or not, and slightly different rounding results in it either just barely fitting or just barely not. That kind of stuff is probably unavoidable, but the solution is as I described: if you want to guarantee a measure starts on a given line, you need to put a line break before it. Otherwise, there is just never really a guarantee wpyou won't see similar roundoff discrepancies in the future. This probably represents a small bug, nut in any case, if you wish to lock in the layout, you absolutely need to get in the habit of using breaks. I recommend adding breaks to the end of every system once you have things as you like, then globally reducing stretch to mkae sure you aren't right on the edge.
In reply to I suspect this is one of by Marc Sabatella
I'm experimenting with some existing scores and it seems to work. I'm still a little concerned if there is - as yet - unknown limits to flexibility when inserting line breaks, but for the moment, the flexibility I get *in between* the lines seems to be holding up. Problem cases much better now. I will let you know if I run into an issue where a Line Break prohibits me from executing an otherwise-normal task.
In reply to Good advice... by greg.winters.10
About the only major "issue" with line breaks is that they cannot be moved, only deleted. If you add extra elements that pushes the final measure in a system down to a new system, it will exist all by itself in that new system. Page breaks have a similar problem.
In reply to About the only major "issue" by schepers
Right, so the standard advice is to wait until you are basically done adding elements before adding line breaks. I also wish there a command to automatcially add line breaks to the end of all lines as they currently are wrapping, rather than needing to manually add the breaks line by lone. But luckily, the types of scores I create where I want that level of control over layout tend to be only 1-4 pages long and adding the breaks a line at a time isn't too bad. I'm also pretty good at anticipating where I'll want my breaks and often ignore the advice to wait until the end: it's a rare lead sheet where I can't fit four bars per lone if I wish.
In reply to Right, so the standard advice by Marc Sabatella
When I would teach MS Word back in the day, one of the most common complaints I got about it was that text would 'jump' all over the place, which was quite disconcerting to the user who had been brought up in the typewriter world. As you know, I have been commenting extensively on this 'condition' in MuseScore, but if you read my posts carefully, you can see that I am not complaining about this feature directly: instead, I am commenting only on the consequences.
I would create examples of the 'jumping text' for my Word students and demonstrate to them how they could learn to trust what Word was doing, and in the end they could see that all was well. My complaints about MuseScore were not about the constant repositioning of the material in the score - they were about how the attached elements and downstream processes did not consistently 'follow' the repositioning activity.
Now that I've gotten used to it and trust it a lot more, I actually *like* this feature. It takes the burden off having to be so 'sequential' when composing the music and parts. I can plug things in here and there, make changes when the mood strikes me, and not worry that I have to get out some sort of virtual eraser or even have to start all over like back in the paper days.
To me, a Line Break is as you say: something that is added when satisfied with the contents of the score at a particular juncture. This is why - on principle - I have resisted the suggestion that they be used in the actual composing process while musical ideas are still being created, just to control the behavior of the elements on the page. If the products of the tools could be forced to adhere to the original expectations of their placements, then the need to herd them along with Line Breaks would be drastically reduced and users could take full advantage of this 'live repositioning' feature.
In reply to On The Fly Composing by greg.winters.10
Yes, so my recommendation would be to focus on the cases where the reflow does not work correctly - where it leaves artefacts, makes items disappear, or whatever - and to see if you can actually come up with a *reproducible* case. i've done probably several hundred scores of various types at this point and can say that I occasionally see glitches like this, but 99% of the time, it works right, and I've yet to come across a *reproducible* case where it fails. The sooner you can get to a reproucible case, the sooner someone can fix it!
In reply to Yes, so my recommendation by Marc Sabatella
OK, I've attached a file that - at least on my end - simply will not open to how I saved it no matter how hard I try. I've also attached screen caps showing the way I want it (when it's saved) and how it appears on my screen when I re-open it. I've performed this altest round of saving and re-opening three straight times. I will be fascinated to learn if this is not happening on your end.
In reply to Reproduceable Case by greg.winters.10
Here's how Glory opened on my system (XP Home SP3 - Musescore 1.1)
![test]( "test")
As you can see this is as you saved the file.
In reply to Reproduceable Case by greg.winters.10
When I tried it last night I had basically the "glory-reopened" layout. This morning I almost had the "glory-saved" layout. This was under the latest 1.2 build.
Now, open the file cleanly and reset the stretch because this file has been adjusted and stretched/compressed so much that some systems are definitely "close to the edge". Now add in your line breaks and everything lines up cleanly, and stays that way between saves. Note that now most systems have 4 bars per line, which is how most of my scores work out. Only the last system on the second page required a stretch adjustment (down) to get the "1.2.3" ending into that system and ended up with 5 measures. I've re-attached the updated score (with other fixes).
I find measure stretch adjustments far too unpredictable and do not rely on them, but instead adjust the "scaling" factor down to fit more on a system (which you already did) and *add line breaks* to guarantee that lines stay the way they are.
Question for LittleReg: why did you score this in C, but in fact the piece is basically in F#? It adds so many sharps that it causes more spacing problems. I've changed the score to F# and fixed a few things (extra note in measure 14, two A's on top of each other on the syllable "Al").
Question for Lasconic: Why does the score "randomly" re-adjust the measures when I simply click somewhere, or move one of the "4X" staff text? This is a common problem, one which you can't demonstrate with a sample score but happens a lot and might be part of LittleReg's complaint.
In reply to When I tried it last night I by schepers
It's helpful to see that not only did the measure respacing problems reoccur - randomly, as I had indicated (instead of consistently), but that there were some of the other elements of the 'jumping' that I had mentioned. Thanks for the updated file!
As to your other question, there are three reasons why I don't use key signatures for these files I've been sending as samples. (Note I didn't say that the music was composed 'in the key of C.') First, has to do with MuseScore itself. Although I haven't mentioned it up until now in this forum, it has been my experience that it has been harder to deal with adding accidentals to notes affected by the key signature than to notes not affected, therefore, the less accidentals there are in the key signature, the less maneuvering I have to do - and what could be less than zero?
For example, ties that would have been associated with accidentals in a key signature are much simpler to 'get right' than if they are already affected. I guess it's something to do with the associated accidental of the notes being associated first, then having to be 'canceled out' by a fresh accidental (including Natural signs). As you know, there are basically two ways to ensure that the pitch of the tied note not only remains the same sonically, but visually: 1) make both notes the same pitch before creating the tie (even if this means adding a second accidental or 'raising' or 'lowering' the pitch accordingly; 2) tie the notes before making any changes at all, then when a change is made to the first note, it will normally affect the second note as well. I like to use both methods depending upon the situation.
Well, I find that the second method is harder to accomplish when the notes are affected by the key signature. In an earler version of MS, when the tie was created, I would notice that there would be times when I would have to 'correct' the second note, especially if I had edited it in the first place. This never seemed to happen when I had no key signature, so I reasoned that the problem had something to do with the second note's association with the key signature that wasn't being 'transmitted' to the tie. I notice that when I *have* used key signatures in v1.1, I don't see this problem any longer.
However, there was a second issue: what happens to the second note when a tie gets broken. Although this was difficult to reproduce, I've attached a screen cap to this post. As you can see, although the pitch function of the note is faithful (over the bar, the note is indeed properly an F-sharp unless otherwise changed), the accidental function seems to have disregarded the key signature and inserted the sharp. This behavior would occur more often with Copy & Paste than manually. This is a nit, however, and as I said, happens relatively infrequently.
The second reason is that I might be composing for people who possess limited musical ability, such as not being well-versed in the nuances of key signatures and accidentals. As they poke through their parts on guitars and keyboards, they associate each pitch with what they are required to play or sing separately. I've been told by most of these people that seeing the music without having to 'refer back' to key signatures is actually helpful to them.
The third reason is that much of modern pop music is not written in 'keys' as was older 'classical' music (which was literally forced to be). I've found that I've spent as much or more time countering key-signature accidentals when arranging modern compositons as I have simply using no key signature and adding accidentals where needed. This is because so much of the modern repertoire has been written in 'tonalities' (instead of 'keys'), and harmonic centers can move all over the place. Besides, if we *were* to assign keys to modern music arrangements, we're only talking about a handful, anyway, and with very few accidentals in them.
As to this third point, however, adding an accidental should be no excuse for the score to jump all over the place. It has been suggested in some of the replies to my posts that the 'added density' is what causes this behavior, but I don't buy into this. This is because when I add the accidental, the score jumps far more forward than the space required to add the mark, and even if it causes the entire measure (or next measure) to move, that's no reason to make that measure triple in horizontal size. In any case, the composer should not be penalized so heavily for adding accidentals. There may be a programmatic reason for this odd behavior, but it should be corrected as the user partners with the solution using tools such as Line Breaks.
Thanks for working on the file!
In reply to Now We're Getting Somewhere by greg.winters.10
"when I add the accidental, the score jumps far more forward than the space required to add the mark,"
See my previous comments about Page Fill and Last Sytem Fill threshold settings - these are definitely responsible for some of the behavoiur you are describing.
In reply to Now We're Getting Somewhere by greg.winters.10
While the two methods of creating ties you mentioned to work, you left out the usual way: enter the first note (complete with accidental) then hit the plus sign. I virtually never would enter both notes first before tying. My guess is whatever other difficulties you experience with using key signature might also stem from simply not doing things the most efficient way, because there is definitely no way it is should be easier to ener music in the wrong key signature in the right key. But fwiw, I too seldom use key signatures in music of any harmonic complexity, for more or less the same reasons as you.
But I don't understand your remark about adding accidentals causing more jumping than necessary. Either a measure fits on the line or not, and if it doesn't because of the added symbol, the entire measure must move to the next line. And that might cause the next measure to move to the next line, and so on. If you can find an example of this not working correctly, again, posting a specific example with steps to reproduce would help, but I've never seen it in the hundreds of pages of scores I have produced.
In reply to While the t methods of by Marc Sabatella
The exposure of the multiple methods of doing something in MS precisely makes my point. When composing on paper, it's highly unusual to create a tie the way you indicate (with this + key). The reason is that the composer using pen and paper would have to have a 'target' to attach the tie (or slur) to, else risk having to be extremely precise where positioning the target note. Thus, as I've done and seen it done for over forty years, the first note is created, then the second note is created, then the tie is created between the two notes - the notes acting as guides for distance and angle.
I could ask this question from another perspective: since MS 'allows' me to do it in both of the two ways I've described, why should I be penalized by lack of quality results by being permitted to perform the process in the first place? With software, if a user *shouldn't* be using a feature a certain way, then s/he shouldn't be *allowed* to use it that way: all feature usage options should be dead equals in terms of results with differences only in effort permitted.
As far as the jumping measures go, I acknowledged that it was reasonable to expect that a single accidental might send the line 'quota' over the limit, so to speak, but what really causes the problems is when that measure that must move suddenly itself doubles in size, obviously kicking ahead everything else and contributing to the domino effect. The only time this kciking ahead should occur is if each and every line were also at *their* limits, as well. However, then that original measure couldn't double in size, right? Sometimes these kicked-ahead measures get so spread out that the distortion makes them almost unreadable.
I've attached an example of a single accidental causing the music and the entire layout to jump everywhere simply by adding it. I'll have to look for the example of the jumping/increasing measure size because I fixed all this my my current file set. I might have to send one along the next time I encounter it, but with the attachment, you can get the idea. The steps to recreate are as follows:
1. Open the file.
2. Select the very last note of Line 2 (pitch = E).
3. Press the Down arrow which adds a flat to the note.
4. Note that the entire measure, instead of simply contracting a tad to accomodate the accidental, jumps to the next line.
5. Note that the Staff Text, guitar tablature, etc., is completely blown out of alignment.
I've removed the Line Break controller just for the sake of demonstrating this point, thanks.
In reply to 'Default' methods permitted by MS by greg.winters.10
Users of pencil and paper aren't expected to rwad the manul. Users of software are. As I said in my first response, I think most of your issues stem from simple unfamiliarity with the program that a few minutes spent with the documentation would help with immensely.
Anyhow, my point with the observation about ties isn"t to say that the other methods shouldn't work. They do work, and quite well. I was just pointing this lut as an example of the act that it would really help if you would gain more familiarity with the progam before suggestion wholesale redeaigns.
As I said, I don't have access to my computer right now, but your description seems perfectly in line with what is expected. If the accidental pushes the line voerfull, *of. Ourse* it pushes the entire npmeansure to the next line, and *of course* that means the other measures are stretched out to take advantage of the fact that there is now one less measure on the lone. Any other beavior would be completely broken. MuseScore, to use word processing terminology, right justifies all but the last line.
In reply to Users of pencil and paper by Marc Sabatella
You (and others) seem to think that I did not read the accompanying documentation before posting to this forum. My question to you is: have *you* read the documentation? Where in the documentation does it explain:
1. That the staffs are 'right-justified' when entering the notation?
2. That the Paste function will not necessarily reproduce what the user sees on his/her screen?
3. That once a user saves a file in a certain format, that when s/he reopens it, the layout might be automatically reconfigured?
4. That if MS reconfigures a layout unexpectedly (for whatever reason), the the best practice is to use Line Breaks to control this behavior?
5. That the + keystroke is recommended best practice for creating a tie as opposed to using the toolbar button?
6. That Reload is the proper way to 'refresh' a screen display (or anything at all about Reload itself)?
7. That MuseScore is deliberately designed to recommend best practice of formatting only when the layout is completed?
8. That 'page margins' apply only to the staff and not to the useable workspace? (The word 'margin' isn't even in the manual.)
9. That text entered in the workspace can not only be moved off of the workspace, but can disappear as well, and that there is a procedure as to how to locate and retrieve it?
10. That the Page Settings preview in the Layout menu can actually show something different that what is in the actual workspace and what to make of that? (The term 'page settings' isn't even in the manual.)
11. How the Stretch tools actually work (not just what keystrokes are associated with them), and what limitations they have as far as using them to align the music?
Allow me to quote 'schepers' if I may: "The manuals can become very stale or wrong quickly." If the Help system (online or otherwise) is allegedly so crucial to my gaining the proper experience I need to avoid the queries I've been making, then why isn't a proper and comprehensive update to the documentation required prior to the insertion of the new functionality into the application?
Believe me, I *much* prefer doco to forums, only because I can trust that the information is right there and I can reserve queries for things that I really can't find. So far by my count, the only things that I've overlooked which were directly contained in the manual were the X 'flip' tool for ties, and the Line Breaks (even though there is nothing mentioned about the latter in terms of controlling measure autosizing). I have not been able to locate any of the rest (listed above).
I've tried to go easy on the document creators and managers. I know that it is indeed challenging to create and update Help systems. I do this as part of my 'day job.' However, there should be nothing that a user sees that should not be contained in the manual exactly how the user sees it. Each and every toolbar button, Menu system entry, column header, title of dialog box, etc., should all have Help doc entries. Layout Menu has a 'Page Settings' entry? Then I should be able to type in "Page Settings" and get a complete overview of how this dialog works, what all the objects are contained in the dialog and how they function, and examples of best practices. This would be nothing more than translating the programming language into plain English.
I'm a little coarse with my dialog here because of the assumption that I didn't read the documentation. If I've missed something, anyone reading this is welcome to show me where it is located and how they found it. I would be most appreciative, believe me.
In reply to Documentation by greg.winters.10
One of the reasons that UI consistency is so crucial is for the very reasons we appeal to documentation and Help: verification of the methods we use to interact with the provided functionality and produce the desired results. The UI is our first line of defense, so to speak, when trusting whether or not we are performing the tasks properly and efficiently.
In the attached file, I show a simple case where 'reverse referencing' can occur due to a breakdown in the consistency of the UI. What I was attempting to do is paste a single Staff Text object (Bb) across multiple (selected) staffs. Note how the Paste function is 'alive and well' - offering the user the ability to perform this function, but as probably everyone who reads the forum and uses MS knows, this request cannot be granted.
However, this is where the logic of investigation breaks down. In a standard UI interaction, a user gives the benefit of the doubt to the UI and trusts that, in this case, because the Paste function is not greyed out (i.e., 'active') in the popup menu, then the *user* must be doing something 'wrong,' not the application. What could this be? The user then searches (in vain) for the method of pasting multiple Staff Text items, all the while believing that s/he has missed some important step(s), since it appears that the application 'wants' to perform the Paste function, but refuses to do so, nonetheless.
Me, I tried other methods, believing that I was the person at fault. I deselected everything, then performed a range-select (Shift-click) of the last three Staff Text entries, then attempted to paste into the following measure. Unsuccessful. Next, I performed the same operation this time using multi-select (CTRL-click). Unsuccessful. Lastly, I attempted to select the three successive entries, then selected three successive measures. Unsuccessful. In each case, however, the Paste function was faithfully displayed as active.
Searching the manual, I found nothing for "paste staff text," "multiple paste," and a few others and found nothing. It would be at this point that I would then dial into the forums to see if anyone has found a way to make that active Paste function work - all the while, still believing that *I* was missing something due to the UI. If we cannot trust what is being displayed to us, what can we trust?
In reply to ...and in reverse... by greg.winters.10
Indeed you have hit upon one of the current weaknesses of the MuseScore UI here.
It would be worth checking to see if there is an active issue on this.
Those of us using MuseScore regularly have got to know what will and won't paste, and use workarounds to cope.
Hopefully issues like this will be fixed sooner rather than later in the trunk, without checking the issue tracker however, there's no way of knowing whether this is fixed or not.
In reply to ...and in reverse... by greg.winters.10
All of what I am writing here is intended for LittleReg and is my opinion after using MS for about 1 year and the small learning curve it has compared to other programs. I've used several music layout programs over the years (and tried others) and none have been as easy to use and flexible as MS has been, regardless of its limitations. I don't read manuals, and so rely mostly on experimenting to gain experience and find what works and what doesn't. I post when I find a bug. I don't complain (anymore) when things don't go the way I would like or expect. I don't expect perfection because MS is free, but MS is _very good_!
The most important thing that LittleReg needs to take into acount is that there is a very limited number of people on the MS development team. I've only witnessed 4-5 doing actual coding over the past year. Most of the time, those people are submitting bug fixes, and only 1-2 doing real coding on new features. This leaves almost everything else, including the manual and help updates, to others. This is why I commented about how the manuals get stale and/or inaccurate. He seems to expect everything succinct, accurate and perfect. In a perfect world, maybe.
Secondly, you get what you pay for. When I spent money on Finale, I expected a product that worked. I expected a help system and online support system that worked and generally thats what I got. Trouble was, I had to keep paying and paying. MS is free, and the people and community that support it will try to help, but this also puts some onus on the user to get familiar with the tool and all its warts, read the help, follow the forums and take advice, experiment and play, etc. Not everything will be accurate, not everything will be consistent, bugs do exist. Get over it and learn from those who have the experience. Report the bugs, partake in updating the manuals and online help instead of just complaining about the state they are in.
In reply to ...and in reverse... by greg.winters.10
(edited)
I can't tell from your posted example what you were trying to accomplish. Looks like you were trying to create chord symbols as staff text rather than as true chords for some reason, and then copying from measure to measure? Had you used chords, it would have worked. For the record, paste *does* work in general, and that it is why it is not greyed out. It just doesn't copy all types of elements. But it would happily have pasted the rests. If there are cases where there is truly nothng selected, then sure, it's a minor bug that the menu isn't greyed, and should simply be reported as such.
Anyhow, if there is something you are trying to do and your first few attempts don't work out, feel free to simply ask here on the forums. That's what they are here for.. We all started out inexperienced, and we all helped each other out here. Chances are there is a simple way to do whatever it is you are trying to do that we can help you with, and if not, a simple enhancement request can be submitted.
In reply to Documentation by greg.winters.10
It's not a question of whether you looked over the documentation at all. What I am saying is that it is clear you don't have much *experience* with the program. That's not a matter of reading the documentation once - experience means experience. Most of the things on your list are not explicitly described in the documentation because this is open soure software and ino one was paid to write a thorough manual explaining every last nuance of the program. It is expected that you will use the documentation as a guide but also experiment and figure things out on your own, and use the forums to get help. No one is blaming you for not yet having that experience. I am simply asking you keep in mind that many of the issues you run into may be the result of that inexperience, and that after spending more time asking questions and figuring things out on your own, you may see that there is no need for the developers to completely rewrite the application from scratch as you have been practically demanding.
In reply to It's not a question of by Marc Sabatella
It's hard chasing this circle of advice around. First, the user is expected to 'gain experience' by using the tool. If trial and error is not sufficient in order to complete a task properly, then the user is exhorted to 'read the documentation.' When that proves unfruitful, then the user is once again directed to gain more experience. Etc.
I can go along with a certain amount of self-learning curve time that must be invested in any new software program. Believe me, I spent a lot of time with this before even learning of this forum, much lest posting to it. I read the user manual and attempted searches on the website. (Text-based searches are hideous ways to get help. The user must depend upon someone's else's phraseology or submit text so general that a multitude of hits must be waded through.) However, I didn't expect to have to *unlearn* in order to use the application (e.g., active Paste, defintion of 'margins,' etc.)
User schepers thinks that I am a perfectionist and that what I am 'demanding' is unrealistic. He doesn't seem to comprehend the difference between design and planning and software 'bugs.' For example, when we were discussing the issue of being able to drag the stem off a note, *that* is a legitimate bug: something that couldn't be planned for and needs to be fixed. I have no problem with bugs - they happen. Something that performs as designed, however, is not a 'bug' - if the results the user receives are difficult or unmanageable, then this is the result of poor planning and impatience.
I've attached a sample Help section on slurs that I created myself from my own 'experience.' I whipped this up in less than two hours without any aforeknowledge as to how the Slur Tool works. There are indeed a number of tweaks which must be made to the work, but my point is that the original programmer - knowing each and every element of the funciton code - could have done a far better job. I'm just a dumb user.
Note in the document how I have framed the layout in a task-based format instead of the incessant "You can..." style that conveys literally nothing to the inexperienced user who knows only music composition as his/her base. Note also how I have included the caveats that should have been easily discernable to the original tester of the code - helping the user understand the things they s/he should watch out for and possibly avoid. And as I've mentioned, this could all certainly be improved, but the point is made.
Users should not be the ones who create the Help system, although they could contribute to it somewhat. I would volunteer to help format the Help material for MuseScore under the requirement that each and every element of a particular tool or function be called out in advance so that it can be noted. Anyone writing code should already be familiar with each and every aspect of the functionality and very little of how it behaves should be a mystery.
I agree wholeheartedly with the blasts at the 'big guys' (e.g., Finale) for foisting spotty product on the general public and insisting that we pay for it. Why do you think that I turned to MuseScore? However, what I had expected was a small, tight application with a limited number of features (example: MS will not accept direct MIDI pitch recognition input from a controller) which would gradually be tuned and expanded. I did not expect to be struggling with interface issues.
My suggestion has been to standardize the MS development process to an explicit GUI standard of behavior and appearance common to all elements. I don't see how that would entail 'rewriting the application from scratch.' The developers of each tool could work separately against those standards, creating and updating the tools along the way. For example, if a user is attempting to Paste something that MS will end up ignoring (leaving the user scratching his/her head), then all that has to be done is correct a few lines of code which will grey out the Paste function until the user has corrected the situation him/herself. I have never suggested that MS should hand-hold the user and 'make it so' with all sorts of additional automatic functionality. (BTW, Paste is a Windows Clipboard function.)
There should be no case where a user is presented with something like the boomerang slur shape from the tool directly. Saying that this is perfectly 'normal' based upon something that was never shaped like that by the user in the first place is akin to saying that a bridge that was built with a 30-degree contour is acceptable because 'all the math worked out.' Any coding that does not check its results actually places more burden upon the user to edit and correct, not less.
A quarter-century of de facto Windows GUI as well as centuries of music composition have created standards which should form the platform architecture for any software development. Code that ignores these doesn't have 'bugs' - it has simply not been planned properly.
It's possible that I am completely barking up the wrong tree here. When I first encountered the MuseScore website via ZD-Net, I got the impression that it was all about an application for *users*, not a sandbox providing a loosely unified context for programmers to test their skills. It seems by the thrust of the replies I've received to my posts that in this sense I am indeed 'asking too much.' With 'coding practice' as the main reason for the existence of the application, adhering to UI and music composition standards becomes far less important.
What is being lost by everyone is the point that I am not attacking MS, but rather *defending* it. I see a wonderful set of fairly sophisticated tools being undermined by the lack of standardization. The whole of it is indeed ingenious and tremendously appreciated. I wouldn't even bother with all this if I didn't think that the application was worthy of such effort.
Again, I am volunteering to assist with the Help docs, but I'd like to base them on the functional specs and not just a menu of features. I can also test new functionality out against the GUI as well as what I know about music (composer-arranger and professional musiciabn for over 40 years, college educated). My motive is to raise the consistency of results in the product by standardizing its usage.
In reply to Which is which? by greg.winters.10
So 4 pages to learn how to add a slur... To compare here is the page in the current handbook : Slur This page has been reviewed by 10 people and translated by at least 20 others in 20 languages. It's probably imperfect, but so far it works.
Comparing to the current handbook, your PDF adds only a long description about using the mouse and then describe some personal particular cases. Currently the whole handbook is more keyboard oriented since keyboard entry is often quicker. Some more mouse entry instructions could be indeed useful...
Thus, if you attempt to establish the range of the
slur prior to insertion……MuseScore will assume that the notes in the range you have selected are separate insertion points, and you will end up with something akin to this:
This seems to be a bug and I can't reproduce in MuseScore 1.1 on Windows or Mac. Clic on a note, shift click on another one in the same staff, press S and you should end up with one slur between the first and the last notes only. Can you open another (short) post with exact steps to reproduce this?
Ctrl + click in MuseScore is NOT used to select a range. It's used to select multiple elements like in any Windows, Mac or Linux UI. To enter a slur, you can select a range (with Shift) or you can select the end and start notes (with Ctrl). Windows users and others will note here that it's the same paradigm than in their beloved OS.
The paragraph about copy paste looks like a truism. If you copy ans paste a slur, and it doesn't look the way you want it to look, yes, you have to edit it... or delete it...
In reply to So 4 pages to learn how to by [DELETED] 5
4 pages, yes, but only a brief read compared to the far-longer system of 'gaining experience' via trial-and-error.
I didn't see the multiple-slur inserts as a bug at all. There are plenty of occasions in music to wish to add multiple like slurs in a passage of music. I was actually pleased to discover this little treat as a part of the functionality!
Steps:
1. Create a series of notes.
2. Select the first note in range.
3. Hold down the Shift key and select the last note in the range.
4. Double-click on the Slur Tool.
(You know, I've found it rather bizarre that for folks allegedly so experienced and knowledgable about the product that they have maintained that I am neither, they have asked me to reproduce the smallest tasks in terms of steps after I've supplied generous details and screen caps.)
CTRL+click in the Slur function indeed selects a range of notes, or are you telling me that the interior notes or rests of the slur are not affected by the slur? This is certainly not obvious by the way that the slur positions itself over the notes, but if true, then we have yet another aspect of how the slur tool works to add to the Help documentation, further proving my point.
The 'truism' of Copy & Paste is that in Windows, unless otherwise indicated by the application, the default condition of Paste will be the *appearance* of the pasted object, followed by the location. The reason for this hierarchy of function is that when using 'select to affect' (how we communicate to objects in the interface), we've already assumed that location is taken care of by the function (our selection). Therefore, our natural expectation is that since it will already be properly positioned by the Paste function, then the original appearance will be preserved, if at all possible. In the case of our slur example, the priority of function would be that when the layout of the pasting area has been manually edited by the user to be similar to that of the copying area, then the appearance of the slur would remain the same, and if stem direction changes, then the slur would simply 'flip' accordingly, since no change has been made to the position spacing. All of these assumptions, as well as what actually happens when the user attempts to do this (as I have demonstrated), make all this hardly a 'truism' by any stretch of the imagination.
The reason this is important - again - is that if the user gets something unexpected (like a boomerang-shaped slur over two perfectly postioned notes), then s/he is inclined to believe that s/he did something 'wrong' or not recommended. Well, where in the docos reviewed by 10 people and translated by 20 others do you find anything that remotely points any of this out. Answer: nowhere.
You casually assume that because of the number of reviewers and translators as well as the lack of feedback you've received that hardly anything I've pointed out in my posts deserves merit. However, you can see how much effort it has taken me just to try and communciate what I'm talking about - how many 'customers' would take the time to go through such difficulties? Chances are, very few.
I can accept the notion that my style of Help documentation does not sit well, so feel free to cast it aside. I only wanted to demonstrate that I'm not just a rock-thrower by providing the actual work representing an example.
In reply to Steps and comment by greg.winters.10
We definitely have a different way of writing documentation and using MuseScore. I agree you are not *only* a rock thrower and thank you for raising several interesting points. You seem to have time to write long posts and detailed help. So go ahead, write more documentation, because that's for sure more helpful and constructive than any rock throwing.
The documentation forum is the right place : http://musescore.org/en/forum/8
Steps are the best written way to describe what you are doing. Especially because they are concise and easy to understand even for non native english speakers. Screenshots are often hard to read if you don't know where you have to look at. That's why we often asked for steps.
I'm not a native english speaker so I might be wrong, but I have the feeling your tone is not very nice when you say "You know, I've found it rather bizarre that for folks allegedly so experienced and knowledgable " and in your "advices" about how to write software. If I'm right, could you be more cautious with your tone? I will not comment further on this specific aspect of this thread to avoid further deviation (Title is still Open & Reopen)
As I said before Ctrl + click in MuseScore is creating a multi selection and not a range selection. That's independent of what you called the Slur tool. (There is no "tool" currently in MuseScore vocabulary, it's more a Finale word I think). When you double click the slur in the palette or press S, MuseScore will check if it's a range selection or two note selected. If it's a range, selection it will create a slur from start to end. If it's two notes, it will create the slur from the first note to the last note.
Apparently, double clicking the slur in the palette and using S doesn't work the same on a range selection. This inconsistency is a bug I believe. I'm not sure which behavior is the best but I think I would prefer the one of the S shortcut (a slur spanning the range)
In reply to Which is which? by greg.winters.10
I think volunteerng to help with the documentation is a good direction. But I also think you are going way overboard in your characterizations because of your lack of perspective. As an example, it is entirely incorrect to say that you need an brand new definiton of margin to use MuseScore. No, you simply need to use the term as it is used in *virtually every other music notation program, as well as virtually every desktop publishing program, in existence*, in which margin settings control certain defaults but don't preculde items from being placed in the margins. Similarly, there is no fundamental difference in how paste works compared to other programs. You simply have to realize that not all element types are pasteable, just as is the case in many other types of programs as well. It's at most a slight adjustment to the specifics of MuseScore (and most other music notation software, whh works exactly* the same way on both counts). These are but two of the many examples of places where I feel more experience would help you gain perspective.
And *of course* there is a never ending cycle of experimentation, reading documentation, and asking questions. That's the way things almost always work when learning a new skill. All I am really saying here is, most of the things you are finding confusing will become less so with more experience, and then you will start to realize that tings are not seriously broken right now - just unfamiliar due to your lack of experience. Things seem confusing at first, and then less so as you gain experience, and it's *nott* the fault of the thing you are trying to learn. It's that way with learning algebra, it's that way with learning a foreign language, it's that way when learning programming, it's that way when learning carpentry, it's that way when learning to play the piano, it's that way when learning music theory, and it's that way with learning MuseScore. Complex systems take time to learn; that's just how it is.
In reply to 'Default' methods permitted by MS by greg.winters.10
Part of this is caused by you trying to format as you go instead of leaving it till the end of the piece. Reducing the stretch by one restores the affected bar to it's proper place at the end of line two. (see first attached)
You might think about adjusting your TAB entry to anchoring the numbers to the notes in the first stave, and then dragging them down to the appropriate place on the TAB staff rather than anchoring them to arbitrary places on the TAB staff. This would then mean your TAB would be tied to the notes and shift when they shift, rather than the chaos which currently ensues when you make a formatting change - see second score with stretch increased on the mentioned bar.
Some tidying up was necessary after I reentered the TAB as when I increased the stretch, characters from your previous editing appeared.
I also took the liberty of making the TAB staff 6 lines and inserting the clef guitarists use at the beginning :)
Sadly I could not get the bar lines to match up without editing each one, and the one at the beginning of each line appears to be uneditable presently. This is despite following instructions in the handbook - is this a new bug? Or is it specific to this score???
Personally I am looking forward very much to the vast improvement in TAB support to be found in version 2.0
In reply to When I tried it last night I by schepers
"This was under the latest 1.2 build."
Where do you get that??
I'd be very interested in test-running it.
In reply to "This was under the latest by ChurchOrganist
He probably self-compiled.
In reply to He probably self-compiled. by chen lung
Ah!
Just looked at what you need for that.
Currently I don't have room for it all - my machine is clogged up with graphics and sound stuff :(
In reply to "This was under the latest by ChurchOrganist
Yessiree, self compiled. Not a small undertaking if your not somewhat into coding.
I like to live on the version edge (branch and trunk), just like Chen does. This way I can keep track of when/if the bugs I've reported get fixed.
In reply to Yessiree, self compiled. Not by schepers
Though I still can't compile properly :D.
In reply to Compile by chen lung
What's the issue with compiling? Just the branch or trunk? Since when?
In reply to What's the issue with by schepers
I always seem to get errors. I did manage once or twice, but it wouldn't play the scores.
I don't have to compile the trunk though, as it's done automatically for Mac :D.
In reply to I always seem to get errors. by chen lung
Is this Windows or Mac specific? I only know the Windows method.
In reply to Reproduceable Case by greg.winters.10
I'm away from my computer and can't try this any time soon, but thanks for getting this to a reproducible case! One thing I can see from the screen shots, though, is that in both versions, you seem to jave reduced the stretch factor too much in the fourth system - that's why the last bar lone has extended off the right end of the staff.
LittleReg1, if some people are having trouble reproducing your reports, maybe you could try a screencast :)?
In reply to LittleReg1, if some people by chen lung
Let's see if the file and screen cap examples I just uploaded will shed some light.