Change duration of multiple notes at once
I'd like to put in a request for the ability to change the duration of all selected notes. Right now, if I try to do that, absolutely nothing happens and I must click and change each individual note.
Do you still have an unanswered question? Please log in first to post your question.
Comments
how you would use this?
It seems to me that this would only add confusion, as if you change durations in a number of bars, there will be added a number of rests in each bar or else, if you increase durations, notes will disappear.
In reply to Please explain by xavierjazz
This is a feature I would use often, if it existed. I'll give you a couple examples from a piece I was just editing - a four-voice choir piece in 4/4 time. In one measure, all four voices enter on the fourth beat. I had entered a dotted half-rest at the beginning of the measure, but wanted to change it to a half-rest and a quarter-rest. Instead of selecting all four dotted half-rests and hitting the period key to remove the dot, I had to select all four individually and do that.
In another section, I had three voices holding a chord across the bar into another measure. I decided I wanted to split the chord into two syllables, which meant I needed to change a whole note slurred to a dotted half to a half note and then another half note slurred to a dotted half (I wanted to split the whole into two halves). If this feature existed (like it does in Sibelius) I would select all three whole notes, change them to halves, and then enter the new half notes in the second half of the measure.
So basically, it's really useful and intuitive for when you have several different parts (as in a choir or orchestra piece) with the same rhythm, and you want to change the rhythm. When I used Sibelius I would mostly use this feature with multiple notes on the same beat.
Could you provide an example of why this would be confusing? I can't for the life of me think of why it would be, unless you had a few notes selected and hit a wrong button, in which case you could just hit undo.
In reply to Explanation by iancboswell
I suspect XavierJazz was thinking horizontally, as was I on reading your first post.
A vertical multiple seclection makes perfect sense, however.
To be able to slect a column of notes and change the time would indeed be very useful in choral and orchestral writing.
In reply to I suspect XavierJazz was by ChurchOrganist
Aha! Yes, horizontal selection would indeed be rather baffling.
In reply to I suspect XavierJazz was by ChurchOrganist
in version 2.0 you’ll be able to split one measure. That’ a step
In reply to Please explain by xavierjazz
If I am composing, especially for multiple instruments, I may need to change note durations in one measure, and this might "break time". Well that's fine. Let me break time, but warn me that time is broken and refuse to play - or refuse to play that measure - until I fix it.
If this means that I have too many beats in a measure, so be it. I will lengthen one note then shorten another. I am the only one allowed to delete what I write, my tools should never do it for me.
In reply to Notes should NEVER disappear.... by Peter Whittaker
Not only would you have too many beats in that measure, but MuseScore would have to change the starting time of all subsequent notes in the measure to accomodate the lengthened note. Changing the start time of notes wothout your permissipn - why would that be any more acceptable than deleting notes without your permission? There are at least as many real world cases where changing start times would be wrong as cases where deleting notes would be wrong. As I've said every time this has come up in the past, I'm not opposed to the idea of a special "insert mode" that moved the start time of some number of subsequent notes every time you changed the length of a given note, but the default is definitely better the way it is now - no start times are changed unnecessarily.
In reply to Not only would you have too by Marc Sabatella
...at least not until the user attempted to play or print or "finalize" the piece. There is nothing wrong with the idea of a "broken time mode" where Musescore marks measures as broken - but there is everything wrong with Musescore changing the duration of other notes when the author is trying to get them balanced correctly themself.
The default Musescore behaviour is automatic time correction, and this is a good thing in a lot of cases. But not at all. Perhaps we simply need a manual time mode. After all, if I am changing the duration of notes, sometimes the right answer is for me to change the time signature. Perhaps I am doing something experimental.
There needs to be a balance between slavish application of the indicated time and author experimentation/expression/correction. Let the author write something that makes no sense or breaks all the rules, that's what we're here for.
How about the following modes:
1. Strict duration correction: Musescore automatically adjusts note duration within a measure to the indicated time. This is similar to default behaviour but without deleting notes*.
2. Strict time correction: Musescore adjusts the time signature of the measure in question, returning to the default time signature in the next applicable measure.
3. Free time editing, limited scope: Musescore lets the user do whatever they want, as long as they remain in the measure (and this would include if they move to the same measure in another staff). As soon as the user tries to leave the measure, Musescore prompts them: "This measure violates the time signature. Would you like to a) mark this measure unplayable and unprintable and correct it later, b) have Musescore adjust note duration to match time signature, or c) have Musescore adjust time signature?"
4. Free time editing, full score: The author is in complete control, Musescore would remind them when they open and save the piece that it is unplayable and unprintable in its current form, time violating measures would be highlighted.
The default would be #1 as now, without note deletion*. But when it happens, a notification could appear that allows the user to select #3 (which would undo the automatic change). The notification would be non-modal and auto-disappearing, like some Windows and Ubuntu notifications. It would appear "slightly away" from where the user is working, so it would not disturb them, but would last just long enough for them to click on it. Once it disappears, an "Info" icon could appear in the toolbar to remind them of this choice (sort of like the "need to reboot" disappearing notification and eventual icon in Ubuntu).
There should also be a way for the user to enter #3, with Musescore marking all "broken" measures and reminding the user at save/print/play that they are there. Not sure how to handle that cleanly, without #3 becoming #4, which is not what is wanted.
* Deleting notes is always wrong: Change the duration, sure, but DO NOT delete. After all, how do you know whether to delete the C, or the Bflat, or the F? You don't, you will get it wrong every time.
In reply to Musescore wouldn't have to do anything at all... by Peter Whittaker
No doubt it possible to completely rewrite the interface and internal representation of music as you describe. But there is no reason to expect it would be any better - just different. Finale works kind of like you describe - it allow broken measures during note entry, but then tries to fix them on leaving that measure. And it generally takes former Finale users (like myself) a few days to make the adjustment to how MuseScore does things. But most of us come to find the MuseScore method is at least as good, perhaps better. MuseScore's method is based on that used in Sibelius, and you don't have to look very hard to find the almost unaminous impression among newcomers to notation sofware that Sibelius is easier to use than Finale. So to the extent there is any objective evidence to go on as opposed to just any one person's preference, it's pretty overwhelmingly in favor of the MuseScore interface,
And I would note everything you describe wanting to do, you *can* do in MuseScore - you just have learn how. For instance, if you want to change the time signature to lengthen a measure, that's fine - just do it *before* lengthening notes. And if you don't want the next note deleted to make room for a note you are lengthening, again, simply copy whatever range of notes you want moved to accomodate *before* lengthening the previous note. Then paste. Works like a charm. Again, it just takes a little while to get used to if you come in with other expectations.
In reply to No doubt it possible to by Marc Sabatella
I've never used Finale or Sibelius, so I cannot comment on those expectations or ways of doing things. (I cannot use Sibelius, no Windows; not much point in trying Finale, given the price - I simply cannot justify the cost.)
As for expectations, well, my expectations are that a piece of software will either help me out or stay out of my way. Sadly, Musescore does neither: it interferes in the worst possible way, changing things on me and forcing me to adopt odd behaviours to prevent the software from doing more than it should.
The hints you provide are good ideas and I can use those. But the fact that users need to learn how to get around the software - not how to use it, how to get around it - points to a major problem in interface design and user experience management.
This isn't a question of learning how to use a system: All software requires the user to learn how to use the software. But good software starts and ends there: One learns how to use it and uses it get things done. Poor software requires not only that one learn how to use the software, but learn its quirks and bizarrities in order to learn how to get around those and get things done. I don't have to fight vim, I just get stuff done in vim. I used to fight OOo all the time, and am hoping that LibreOffice has fixed some of those quirks (I cannot stand Windows, but MS got a lot of Office "right" in that sense.)
The "just cut and paste" hint is one such thing: An extra step the user has to learn to get done what they want to do, a step that has nothing to do with composition or editing and everything to do with violated user experience expectations and adapting one's behaviour to the software.
As for the specific question of lengthening the time signature, well, I don't know that I want to do that. I doubt it. But I'm not certain. I'm composing a piece with at least 6 parts (aiming for over 30, eventually), and I can hear parts of it in my head, and other parts I need to figure out as I go along. Changing a note here or there has downstream effects and effects on other parts; sometimes I need to have things in a mixed up state for a while as I stare at the parts and figure out what needs to change to get things aligned.
I need the software to get out of the way and let me tinker. I'm not writing 16 bar blues.
I've been evaluating a few packages over the last few days. Rosegarden and Canorus were easy to dismiss. Denemo and Musescore not so much, they are both oh so close. (Canorus: no keyboard navigation, we're done; Rosegarden, isn't really a scorewriter, it just has some sop capabilities tacked on)
Musescore looks much better, has the screen organized as I think it should be (score front and centre, tools around the side), has better playback and better understanding of what I've written, and better support for key musical features, e.g., anacrusis. But it's keyboard navigation is abysmal (and everyone who says "just use the mouse" really needs to stop channelling the 1980s and learn something about accessibility and efficient workflow). Denemo is much, much easier to use from the keyboard, much easier, but lacks undo (which is mind boggling - perhaps it is just the version in the Ubuntu repos, I don't know), has odd screen layout, an odd split between score editing and print layout views, and no support for anacrusis*.
If Musescore had Denemo's keyboard navigation, I would adopt it hands down, even with its quirks. But the keyboard navigation is so bizarre (where it exists at all), and the effects of some keys in some modes so bizarre, that I continue back and forth...
...so much so that I am investigating import/export capabilities. If I can get data formats exchanged between the two packages cleanly, I could get something close to the best of both worlds. Unfortunately, they don't seem to support the same formats, at least not as far as I can tell so far. More investigations on that tomorrow. I'm willing to play with command line conversion tools, I know we're at that point in the history of this sort of software.
* Interesting Denemo bug: Start a piece with a half rest, then quarter rest, then pair of eighth notes, in order to simulate anacrusis, and Denemo will conclude that the play time for your three measure piece is somewhere around 70 seconds. Have all the same notes without the leading rests, and play time is a few seconds. Cool, eh?
In reply to Expectations - not what you expect (which is the point).... by Peter Whittaker
Regarding note entry.
There has been talk of adding a scratchpad where you can play around with notes without the limits imposed on this by MuseScore's strict measure philosophy, and then copy the result into a bar when done. I would wholly support such an addition.
Not sure when this will happen (if ever) but it is one way of dealing the problem you have of not being able to trial durations etc
Personally I have no problem with MuseScore's way of working, as I tend to crystallise things in my head before I commit to score, but there are occasions when I wish Finale's fix it afterwards approach was available.
The other thing you can do is use a temporary time signature (say 32/4 for example) which will enable you to play around with notes and not experience MuseScore deleting them.
Regarding keyboard shortcuts - you are aware that the entire keyboard shortcut system is completely customisable?
So if you find the existing keyboard settings unintuitive, I suggest you spend an hour or so working out your own system, and then configure it into MuseScore.
HTH
Michael
In reply to Regarding note entry. There by ChurchOrganist
Michael, thanks for the detailed comments. The 32/4 idea is interesting, I will try that*.
Re keyboard shortcut customizations, I would like that to be do-able, but I'm not sure that it is. For example, see the last comment in thread http://musescore.org/en/node/12739 - if that comment is incorrect, then the correct information is needed to steer people in the right direction; if the comment is correct, then keyboard navigation is incomplete. Also see my thread http://musescore.org/en/node/13849 - keyboard shortcuts do different things depending on mode (which makes perfect sense) but the keyboard mapping utility (at least the GUI) and the action definitions (at least as presented in the GUI) do not distinguish between modes; ideally, there would be a note-edit or note-entry mode and a navigation mode, and one could have different actions assigned to common keys, e.g., up/down mean line up/down in nav mode, but note up/down in edit; ctrl-up/down mean staff up/down in nav, but octave-up/down in edit; etc.
I suspect there are bugs in navigation handling anyway, see http://musescore.org/en/node/13851 - this could impact any well-defined set of mappings.
See also my comment http://musescore.org/en/node/6477#comment-47757 - there are inconsistencies in current mappings, but perhaps these could be corrected with a well defined set of mappings.
(FWIW, while we're on the topic, there is also http://musescore.org/en/node/10995#comment-47760 - sort of on topic, violation of least surprise and too much helpfulness when jumping to a measure.)
One thing that would be truly useful would be to have a shortcut mapping import/export function directly on the shortcuts preferences tab: Yes, shortcuts are being saved to a file, and yes, it would be possible for a user to go about finding that file in the file system in order to share it with someone else, but then the recipient has the error prone task of putting in the right place (especially problematic cross platform).
Ideally, the shortcuts preferences screen would have the following set of functions:
1. Save current shortcuts (currently, one has one's defined shortcuts or the factory default list, that's it).
2. Select shortcut profile from saved list (with factory defaults being one item in the list)
3. Import shortcut profile (use case: recipient gets profile from another user, saves it to their desktop, imports it, never needs to walk the file system - which is frightening for computer naive users, and error prone - solving the cross-platform issue)
4. Export shortcut profile (use case: sender saves a profile to their desktop, uploads or emails it to the recipient in #3)
Gold-plated functionality:
5. Share profile with MuseScore community
6. Browse shortcut profiles on MuseScore community site and import as desired.
If we had 1-4, the first thing I would do is define a set of Denemo-like shortcuts; if we had 5-6, I'd share them with the world!
(But is this possible? I really like the Denemo action of adding a note (like MuseScore), then using up-down and enter to add another; the MuseScore equivalent is shift-note, so the Denemo action might almost require a macro-like function - I ain't writin' no Python! - along the lines of "leave note entry; nav up/down; invoke add-note-here action".)
* What about a scratchpad time signature? That would be the simplest solution, yeah? User changes time signature to X/n or to n/X, where X is literally X, and n is an actual number, depending on what the user is trying to accomplish. Say I'm in 3/4, and need to violate time, but I don't know if I need 3/8 or 4/4; I start by using 3/X, play around... ...OK, complex. Simplify: If the user enters an X in either part of the time signature, they enter scratch pad mode: MuseScore accepts whatever until the next well-defined time signature**.
** It would also be good to have an advanced user preference: When violating time signature, give the user the choice of 1) auto-note-deletion (current behavior); 2) auto-duration adjustment of subsequent notes; 3) auto-signature-change for current measure; and 4) auto-scratchpad for current measure***.
***If a user chooses #4, it would be good to have an information icon on the scratchpad time signature that allowed the user to "extend by M measures" or "extend to measure M": MuseScore would insert the original time signature in measure M+1, to give the user more playing room.
In reply to Expectations - not what you expect (which is the point).... by Peter Whittaker
You can call it "getting around the software" all you like, but it's still just using the software. Although you suggest that for some unexplained reason MuseScore should be different from all other programs that require you to understand how they work first, it isn't. The first time you ever used a word processor, there was likely nothing intuitive about it. But fortunately, most word processors are similar enough that experence carries over. And that is actually a reason why it is a *good* thing that MuseScore,s use model is based on that of the single most popular notation proram in the entire world (which, BTW, runs on Mac as well as Windows, but not Linux except throu emulators and other similar devices).
Anyhow, learning MuseScore really is no different than learning to use any other program - you start by grasping the basic principles by which it works, then you starting working within that system. Everyone comes in with different expectations as to how things might work, so no program can possibly "just stay out of the way" for everyone. If it happens to work the way you expected, it will seem to be staying put of your way. MIf it happens to work differently, it will seem to fight you until you adjust your expectations. But if the program were changed to meet *your* expectations and hence stay out of *your* way, then it wold be getting in the way of the people who come in with different expectations. There is simply no way for a program of any complexity to meet everyone's expectations right out of the box, unless everyone's expectations have all been set the same way by familiarity with pther software, the we are familiar with basic word processing use models. When it comes to software for which there is as yet no universal standard use model, you just have to accept that you might need to change your expectations a bit. Again, once you grasp how it works, it ends up being very simple, it just might take a minute to get there.
As an example, you say cut and paste to move notes is an extra step, but it isn't if you understand the use model. You are asking for the start time of notes to chane. Why *shouldn't* that require an explicit step? MuseScore should not be in the business of changing start times of notes without your permission. In most cases, that would be disastrous. Consider a desktop publishing program - if you delete one element from a page, does it move all other elements to cover up the space left behind? No, and you would be very upset if it did. You accept that once an element is placed in a desktop publishing program, it's position is fixed, and this makes it inherently unlike a word processor in how things flow, because these types of programs have different use models. A desktop publishing proram generally expects that elements have fixed positions, and they don't move until you move them. Music can be thought of similarly - notes have fixed start time positions, and shouldn't move unless you move them? Of course, it is also possible to think of music more like a word processor. So thee is bpund to be some confusion at first, as everyone is going to come in with slightly different expectations on issues like this. Simply put, has elements of both word processing and desktop publishing, and each program will resolve this using its own use model since there isn't a universal standard for such things the way Office has become for word processing. But once you grasp the use model of a given program, things can seem quite natural.
As for keyboard navigation, it would help if you explianed the specific things you have issues with - most likely it is a simple misunderstanding about the basic use model. Also, as Michael observes, you can customize most shortcuts. But thee are indeed a few places here and there where keyboard navigation could be improved, and there are outstanding feature requests in the issue tracket for several of those. if find more opportunities for enhancement, feel free to post feature requests of your own - but do start by posting in the forum to be sure it isn't a simple misunderstanding.
As for import/export, MusicXML is the universal language supported by all notations that are worth a dime.
In reply to You can call it "getting by Marc Sabatella
Of course all systems need to be learned. The good ones only require that the use learn things that make sense, things that are required to do the work at hand. Poor systems require that the user learn extra and unnecessary steps. Good ones don't make users do extra work outside their expected workflow.
Telling me to cut-and-paste is conceptually exactly the same action as telling me to write the notes on a paper outside the application: I have to take extra steps because of a deficiency in UI design and I have to remember to take those steps. I probably learn to take those steps by failing to take them repeatedly, and eventually I learn them through frustration.
In both cases (the cut-and-paste and the paper pad), the behaviour at play is that the program requires a temporary storage buffer outside of normal workflow to compensate for a program behaviour that is not desired, that is poorly aligned with user expectations and user wishes.
Have you ever pushed a door marked pull or vice versa or seen someone do the same? Of course you have, we all have. We all know how doors work, we figured that out before we go to kindergarten. So why do we do it? Because we are illiterate? Of course not. We do it because of fundamental conflict between a low level brain function and high level brain function, a conflict caused by the person who implemented the handle without taking into account user interface design and user expectations.
Put a "push" handle (a flat slightly angled bar) on a door marked "pull" and most of us will push it until we learn that this interface is backwards. Likewise, put pull bars on a door marked push and most of us will pull the door open until we remember by force of error that this one needs to be pushed.
The low level brain function is simple visual pattern recognition interpreting the pull handle as a bar to be grasped with the hand and pulled towards us, and interpreting the flat panel as a good place to place one's palm and push. Simple mechanics in both cases. We process those clues faster and at a lower level than we read.
Hence the conflict, and our eventual frustration and embarrassment that we got it wrong when the words were right there, duh. But the fault lies with the designer of the door, not ourselves.
Likewise, software UI and software UX should be consistent with user intention. My intention is not to use software and learns its quirks and foibles, my intention is to compose music, to put notes down. Software is the most convenient way to do so. Good software should let me get this done, and should let me choose how helpful I want the software to be.
When I need to use a temporary external buffer to preserve my work, the software is doing it wrong.
The MuseScore UI is close to great, the UX less so, because of the inconsistencies with keyboard shortcuts, because of unconfigurable destructive automatic behaviour.
All I want is for this to be my favourite piece of software. For that, it needs to observe the design principles that all other good software observes: least surprise; non-destruction; stay in the flow; etc.
Re desktop publishing not moving stuff: I agree. But why is it OK for MuseScore to delete notes but not OK to change duration? That is a perfectly inconsistent stance.
Re programs not being able to conform to user expectations: Complete tosh, actually. That's the point of separating presentation from execution, the point of MVC and other models, the point of APIs, etc. If there was only one right way to do things, we wouldn't have so many competing programs, we'd have one that does the right thing. If there was only one right way to do things, we wouldn't have remappable keyboard shortcuts, etc., we wouldn't need them.
Re keyboard shortcuts: Obviously there are problems, I've discovered quite a few in quite a short time. But I am not a mouse guy, so it is easy for me to find them. My goal is to get them fixed the right way, by which I mean in a well-considered system design that separates interface and execution with a well-considered configurable UI leading to a well developed UX, one under user control.
Re MusicXML: I might well agree with that it is a universal language* that should be universally supported*. It isn't, yet, and the "worth a dime" comment is both arrogant and unhelpful. Helpful would be sharing the knowledge you do have of what formats are supported by various tools and scripts or recipes for automated conversion between formats. After all, we should want to be able to get everyone using our favourite tool, yes? That would require well-defined, low-risk, non-destructive data conversion recipes that naive computer users can employ with a high percentage of success and minimal manual post-conversion or post-import fiddling/correcting.
* Discussions re modernization, adoption of an XSD instead of a DTD, and eventual alignment with W3C or ISO standardization efforts notwithstanding.
In reply to Don't laugh when someone pushes a pull door.... by Peter Whittaker
Everything you say still comes from expectations based on a preconceived notion of how things should work and not taking the time to get inside how the use model really works. You speak of copy and pasting as a workaround for things getting deleted, because your use model says that notes are just symbols to be pushed around, while not taking into consideration the use model that says that notes have a specific start time and what you are suggesting would *change* that start time. The MuseScore use model might differ from *your* expectation, but it's the use model of the single most popular notation in the world (Sibelius), so saying it doesn't match what "the user" expects is like saying your expectations are more universal than those of thousands upon thousands Sibelius users. somehow, I have trouble accepting that. Just because these programs don't fit your particular expectation still doesn't make them wrong or bad. Just different.
You can spend a lifetime looking for a program that fits your preconceived notions of how things should work, or you could spend a couple of days familiarizing yourself with how any given program actually works. Your choice, but as someone who has been there, done that (four different times with four different programs, all of which worked very differently from each other), I can assure you it needn't take long to start feeling comfortable with a different use model than one's initial expectations. It can be frustrating at first, but once you have it, you have it.
As for the apparent inconsistency between saying it's not OK for MuseScore to change start times of notes without being told but is OK to delete notes, all I can say is, music might be similar in some ways to desktop publishing, but it is its own thing too. The best DTP analogy would be if MuseScore didn't delete the subsequent notes when you lengthened one, but rather, overlapped them, hiding the second note behind the newly enlarged first. I doubt that many people would find that behavior expected or desirable, though. Nor would they want to see the paper size change every time you added or deleted an an object in a DTP program, whoch would be the analogy of allowing "broken" measures (measures with the wrong number of beats).
Pretty much no matter what assumptions you go in with, they are likely to turn out to be wrong at some point. That's why I keep saying that ultimately, you simply have to accept that you are going to to adapt to a new use model, because there is no other existing use model that would make a perfect analogy. The only programs out there that MuseScore could reasonably have chosen as a basis for its use model were Sibelius and Finale - not a word processor, and not a DTP program. And between Sibelius and Fnale, while it is in some senses flipping a coin as to which use model to choose and both have advantages and disadvantages, numbers and reputation for ease of use point to Sibelius as the more reasonable choice.
In reply to Everything you say still by Marc Sabatella
"The only programs out there that MuseScore could reasonably have chosen as a basis for its use model were Sibelius and Finale"
Ah! Here is the crux of the matter, where we must agree to be in violent disagreement. Why should MuseScore have adopted either approach? Are they the only two in the universe or the only two in active commercial implementations? Obviously, they are the latter.
Consider how long MP3 players have been around. Many, many years. Then Apple invents the iPod, and all of sudden most consumers think Apple invented the MP3 player. Why? Because of a wheel and a button. I am no Apple fanboi, but I recognize devotion to design and UX when I see it.
I've been an Open Source guy for a very long time and run my business (small as it might be) on Open Source software (except for accounting, sigh, pick your battles). One of the most important and most common criticisms of Open Source developers and projects is second-rate UI and UX and developers mimicking the behaviour of other systems instead of building better systems.
I really don't care what Sibelius and Finale do. So far, Denemo is easier to use and more efficient to use than MuseScore, but is uglier (screen layout is terribly poor) and more dangerous (no undo). Add that to the baffling edit/print duality, a duality that does not exist in MuseScore, and it becomes apparent that MuseScore developers have consider the UI and presentation in general more carefully than the Denemo developers. But the lack of attention to detail keyboard shortcuts - and the inconsistencies therein - shows a lack of attention to detail in UX design. (Canorus suffers from the same flaw, it seems.)
So why do I invest such much time here? Because my assessment of the underlying capabilities of the two systems suggests strongly that MuseScore is more likely to be the one that can be adapted to proper system and software architecture and appropriate levels of user configurability and accessibility.
Really, why would one settle for "that's just the way it is" and not advocate for "this is how great we can make it"?
This is software. We can make it do anything we want it to. Don't ask what others are doing. Ask yourself what you really want.
What would blow your mind?
Ask for that.
In reply to Why use another program as a basis? by Peter Whittaker
Why create programs that work similarity to how other programs work? Familiarity. Millions of people will expect any new program to be roughly similar to others that serve a similar purpose, and they will be instantly comfortable with a new program if it turns out to be similar to the one they are most familiar with. This is the same reason virtually all word processors implement a similar use model - it's well understood, people expect it, and they are therefore instantly comfortable with it. If it ain't broke, don't fix it. Could someone invent a wholly new unheard of use model and convince people to change their ways to adopt it? Probably, and it might even be successful. Feel free to pursue that avenue yourself. But every iPod that succeeds by doing things differently, there are a thousand products that fail bexause they don't meet expectations of familiarity. I think the MuseScore people made the right choice in not reinventing a wheel that didn't need reinventing, especially given I still see no reason to believe here isn objectively better way out there. What you describe is not unlike Finale, and as someone with years of experience with that, and a year now MuseScore, I can unequivocably state there are tradeoffs. Some things are slightly easier the Finale way, some slightly easier the MuseScore way, but overall, it's six of one, a half dozen of the other.
Anyhow, we can keep around in circles on this if you like, but the bottom line is this. The type of use model you suggest would work fine, I'm sure, and compared to others it would have advantages and disadvantages. I'm not trying to tell you your ideas couldn't have worked too. I am simply asking you consider that other use models have merit too. Give MuseScore a chance and it may end up blowing your mind, too.
In reply to Don't laugh when someone pushes a pull door.... by Peter Whittaker
Btw, not sure what you thought was arrogant about my MusicXML comments. As far as I know, all professional quality or even sort of close to professional quality programs provide MusicXML interchange. If there is a particular favorite program of your that does not, I didn't intend to slight it. i just honestly don't know of any serious proram that don't provide this. And there is no special knowledge required to use it - most programs have a simple command in the File menu to load/import from or save/eort to MusicXML.
In reply to Btw, not sure what you by Marc Sabatella
The arrogance was in stating that it is a format supported by all systems worth a dime. Is it worthwhile to support it? In the absence of other systems (but take note of Open Score Format), perhaps. Is not adopting it a sign of an inferior system? Absolutely not.
The unhelpful part was in side-stepping the question of format conversion. There is a system in which keyboard navigation simply work better than MuseScore; format conversion between the two (to address fundamental musical capabilities lacking in the other, e.g., anacrusis) would be a step forward.
In reply to MusicXML... by Peter Whittaker
Is there a specific program you think worth a dime that does not do MusicXML? If so, I'll happily make an exception for it. As I said, I'm just not aware of any. But I don't know what you mean about sidestepping. The question was, is there a standard way to convert between programs, and the answer is yes: MusicXML. eems very straightforward to me, so I'm having difficulty understanding what you fnd objectionable.
In reply to Is there a specific program by Marc Sabatella
is hard to understand in text.
Violin.
In reply to Is there a specific program by Marc Sabatella
So far, I think Denemo is worth a dime, compared with MuseScore buck fifty. And sadly it does not do MusicXML. It does do XML, but it writes it compressed (though I've just discovered one can generate the straight XML with gunzip: cat file1.dnm | gunzip > file1.xml).
I've tried taking a MusicXML and creating a compressed file for Denemo (gzip -c file2.xml > file2.dnm) but Denemo merely explodes, sigh.
What I find objectionable is the overall tone of your posts on import/export: "MusicXML or the highway, chump". You appear to know far more than me about the capabilities of various scorewriters, but you don't share much....
(Sadly, this is consistent with most fora these days, such as the one herein wherein 't'was suggested one should merely define a shortcut for some specific action to solve one's trivial problem... ...only said action did not and does not yet exist... ...sigh. Do we really need comparative discussions to turn into KDE V Gnome, emacs V vi, BSD V GPL? No, not really.)
In reply to Tone and attitude Vs actual helping.... by Peter Whittaker
Well, I'd definitely make an exception for Denemo, because it isn't really a standalone notation program per se It's a front end for the text-based Lilypond system. So it make sense that Denemo itself wouldn't provide MusicXML interchange directly. It's architecture is such that it would be natural for it to simply rely on the existence of converters between Lilypond and MusicXML. In other words, it's not really Denemo's job to do that conversion. I understand the Lilypond folks do have converters that go at least one way reasonably well (XML to LY), the other way maybe not so well. So I can see that it would be in the interest of the Denemo folks to implement MusicXML output, seeing as there would otherwise not be a great way to get MusicXML from it as there would be if ly2xml really existed and worked. But I certainly don't hold any lack of MusicXML interchange against Denemo, and it was never my intent to imply that.
Anyhow, I was not trying to say I think MusicXML is the way programs *should* go. It is a simple statement of fact - MusicXML is the only interchange format in existence that has any acceptance at all. This really shouldn't be a controversial statement. There are essentially no competitors to MusicXML whatsoever. It is not me that has decided this, but the developers of notation programs, virtually all of whom have implemented MusicXML (or contracted with Recordare to have this facility developed for them), and virtually none of who have proposed or implemented anything else. Again, that's just how it is, not my take on how I think things should be.
Now, if you were to ask me how things *should* be, you'd hear me advocating ABC as a very interesting alternative, since it is far more human readable - and, more importantly, human writable - than MusicXML. I might also advocate developing a new format that is basically an enhanced MIDI file with extra messages for notation elements, modeled in part on how Notator used to do things 20 years ago. But selling any other applications on either of these would be a huge uphill battle.
But again, I'm not talking about how I think they should be, but simply telling you how they are. Sorry if I somehow gave you the impression otherwise.
In reply to Well, I'd definitely make an by Marc Sabatella
ABC looks interesting, but has the disadvantage of being an old-fashioned, typeless, unvalidatable text-only representation. MusicXML improves upon that, but remains unvalidatable, given its DTD basis; a future system based on an XSD would improve that as well. I don't know if Open Score Format (based on MusicXML, extended via Dublin Core) gets there, I haven't looked into that much due to the apparent lack of support for this format in major apps so far.
What puzzles me about MusicXML is that I've never before seen a copyrighted DTD. Proprietary copyrighting of a data format is the antithesis of open format specifications - perhaps we'll get to the right place with Open Score Format, if they can a) get MakeMusic to contribute it to "b" and b) do one of two common things, b1) create an open, openly governed foundation to manage OSF, or b2) transfer it to an appropriate standards body.
But these are all future "shoulds".
For the present, my main concern/question in the above is/was: Given the lack of common formats across various apps, what are some (perhaps command line) scripts and recipes for converting from a format well-understood by MuseScore to one well-understood by Denemo, and vice-versa.
I can imagine and accept an answer along the lines of: For MS2D, save as fmt1, run cmd1 to create fmt2, import fmt2 into Denemo, and for D2MS, save as fmt3, run cmd2 to create fmt4 and cmd3 to create fmt1, then import fmt1 into MuseScore. (Any of cmd[1-3] could actually be pipes of various commands, using compress/uncompress functions as necessary....)
Complex? Sure, but scriptable, if cmd[1-3] are command line and controllable via command line parameters. If I can get to that point, heck, I can write python to do it automatically in either program, yeah?
Baby steps....
In reply to No worries, I think we are on the right track.... by Peter Whittaker
MuseScore can be used as a filter, for all the formats it understands.
See for example http://musescore.org/en/node/12452#comment-42050, where I'm using 'make' to convert mscz files into xml and pdf.
That can also be done inside a running MuseScore, using the Batch Export plugin (done by Marc and me)
In reply to Scripting by Jojo-Schmitz
You've just activated brain cells that have been dormant a long, long time. I feel inference rules popping back into my head as I type this.
I will play with this a bit....
JIC this works less well than I am hoping, do you have any experience with Linux command line utilities in this area?
Re spaces in filenames: If you want to stick with make (which may be easier to get working cross-platform than using arbitrary scripts - unless one were to write platform specific globbing scripts in the makefile and invoke appropriately with a platform detection technique... ...hmm...), then you might consider the "remove 'em" and "put 'em back" functions on http://www.cmcrossroads.com/ask-mr-make/7859-gnu-make-meets-file-names-… (the page is for Gnu make, but since the functions are defined using standard makefile syntax, they probably work cross-platform; it's been a long time so I cannot remember what the makefile rules themselves have to say about spaces, but probably best to rely on functions than splotchy support for spaces in various automatic variables).
Another alternative might be to use the W modified as documented on http://www.opussoftware.com/tutorial/TutMakefile.htm, but I dunno about that, one might need a way to put 'em back in again (cf previous para).
In reply to make? AYKM? Cool! by Peter Whittaker
Well, I gave up on make and blanks in filenames, could not get them to work, so I manualy renamed all my scores.
I'm now using the batch export plugin, that doesn't have this issue and is, esp. on Windows, much lighter (no Cygwin needed), so I could start using blanks again ;-)
In reply to No worries, I think we are on the right track.... by Peter Whittaker
The problem will be, each translation is going to lose a bit of info, as no converters are perfect. Most direct way to get from MuseScore to Denemo would be MusicXML out of MuseScore, which preserves "most" of what is in MuseScore, then import that into Denemo. Iit presumably uses the MusicXML to LY converter, which I gather preserves only "much" of what was in the MusicXML. So you've got two generation losses to deal with. Chances are you'll lose a good bit of formatting, and might have issues with multiple voices, but simple music should come through OK. Going the reverse will depend on your ability to find a decent LilyPond to MusicXML converter. All logic suggests that such a thing should exist and be pretty robust, but I don't know that this is actualy the case. So you might have to resort to MIDI output from Denemo, which is guarantee to lose pretty much everything but the notes themselves, and may also mangle complex rhythms somewhat on import into MuseScore. Again, multiple voices will probably be problematic.
Realistically, I doubt that the results of conversion in either direction will be good enough to make this worthwhile - whatever advantage you gain from having access to both both prorams will be negated by the disadvantage of information loss. But if you do decide to try and have issues with it that are worth discussing here, I'd encourage you to start a new thread on that topic, because we're pretty far from the original topic here.
In reply to The problem will be, each by Marc Sabatella
...and so far I cannot even get Denemo to open/recognize a MusicXML file. Either it dies (if I try with a compressed XML file) or simply refuses to open the file (load failed).
Starting to seem like a dead-end, which is too bad, because the keyboard navigation in Denemo is better defined than MuseScore (where there appear to be missing actions). I may need to learn to live with these, poop. I hate mice... ...well, I'm not terribly fond of them, hate's a strong word.
I just entered a whole piece of music as crotchets.
When I sped it up to maximum, it wasn't fast enough for me, so I want to change all the notes to 1/32 notes.
This is an example of wanting to change all note durations at once.
Can it be done?
Steve
In reply to I just entered a whole piece by stevelc777
Not currently. Not sure what you mean by "maximum" tempo though - you can enter ridiculously fast tempos in tempo text. Maybe you were trying to use the play Panel to temporarily override the really tempo by providing a scaling factor, and I guess that has a maximum scaling factor, but entering a fast actual tempo via a tempo text (see Text palette, or click a note and press Alt+T) should work fine.
I think that's would be a great feature too.
Just like you may select a whole sentence to make it bold in most text editors, we should be able to do this with Musescore, as duration is an essential aspect of music notation. But instead of changing to one new duration the whole selection, make it change relative to each original note duration, so that all 1/4 notes become 1/8, while 1/8 become 1/16 and so on ... that's an example
I want to point out that in the Handbook it currently is written:
Note: It is possible to copy and paste the pitch of a note only (and no other properties), by clicking on the notehead and applying the standard copy and paste procedure. The pitch of the destination note changes to match that of the copied note but the duration remains the same.
So, one can copy a note and select another position that is of a different duration and paste that pitch into it easily. This is nice, but for some reason MuseScore won't let you do this with multiple notes. If multiple pitches could be copied and pasted then it would allow for the same thing as requested for a change in duration of multiple notes in a slightly different manner.
For instance, if I have a passage of a lot of beamed eighth notes and I want them to be non-beamed quarter notes, if this multiple copy/pasting was properly working I could copy just the pitch of thirty-two eighth notes and then past them into thirty-two quarter notes, thus allowing me to then replace the original passage as I see fit. This requires extra work (having to have extra measures for the copy and pasting), but it would make sense if MuseScore could do this. If it can do one note at a time for copying and pasting pitches, one would think multiples ought not be a problem ;)
I would like this too. Sounds quite useful, particularly in complex pieces. There should be two speed/tempo options for notes and the choice of overwriting notes/adding rests after the changed notes or shifting notes after the changed notes (to the end of the changed notes' new length):
The two speed/tempo options:
#1: Set all selected notes to the specified beat length (mainly useful in chords/parts of chords/notes of the same length).
#2: Set all selected notes to a percentage/fraction/decimal (part) of their original lengths (useful for notes with different lengths that need to be sped up/slowed down).
This feature apparently is already in Sibelius so must be popular and useful. Please add it - it simplifies work and is useful.
I 2nd this request, I can't believe how hard doing anything is in this tool.
I want to change 4 notes to be quarter notes, then add a couple more notes - impossible? or just incredible complicated ? Basically I always seem to have to just delete the bar and start again because simply 'editing' is WAY harder than it should be!!!
I can click a single note and change it's duration, but now I have an unwanted rest added to the bar ? seriously?
It's like when I delete a note, I get a rest added that I didn't want. See screenshot.
This program definitely needs a 'simple edit' mode - one where I can simply add / delete / edit notes or multiple notes and it simple does what I say ( no extra rests appearing ) - Then I can go fix any timing issues in the bar when I'm ready to.
In reply to I 2nd this request, I can't… by danteuk
Indeed, there is no mode that allows you to enter rhythms incorrect and them change them en masse. The assumption in MsueScore is if you take the time to enter a note, you are doing it because you want it to be in exactly that position, so changing the duration of some earlier note won't magically move all the rest of your notes. So instead, if you change the duration of some note and want others move,d just do it directly, via cut and paste. Obviously this ends up meaning it is important to get rhythms more or less correct the first time. And yes, some day a new "scratch pad" mode might be implemented to help with those sort of changes. But meanwhile, once you get used to how things work, you'll find it's actually pretty natural and easy to do most things. Like anything else, there is a learning curve. Hang in there!
In reply to I 2nd this request, I can't… by danteuk
Any news on this topic? It's a long thread, but I really need to be able to change the duration of several selected (vertical) chord notes at the same time. It is really cumbersome to select them and edit one at a time.