Stop showing superfluous rests (where another voice is playing a note, there should not be a rest)

• Dec 22, 2016 - 05:44

One thing that really bugs me is having to clear up the clutter of extra rests, which shouldn't be there because one of the voices in that bar is playing a note.

It's not that I'm fussy, or a neat freak - they make it harder for me to see the notes I'm trying to play.

This happens a lot when I import from MIDI, and there is more than one voice on a stave - e.g. more than one finger, playing a piano.

I can't imagine anyone sitting down with a quill, writing out some music with the odd chord in it, and deliberately writing in rests over the top of notes - unless they'd lost their marbles, possibly.

Please make that stop, in the new version. Put simply; where there's a note playing, there is not a rest in the same place. Rests are what happens when no fingers at all are busy playing a note. There is no other reason to show one.

I try tricks to remove them, like swapping voices 1 and 2, in bars where it happens the most, then deleting all rests - which usually generates a few more. Ultimately, I go through it hiding individual extra rests which are just cluttering up the page, and then hide all invisible elements. I feel strongly that no one should ever have to do that again.

Comments

• Dec 22, 2016 - 06:12

To be clear, I'm talking about rests which occupy the same exact time as a note, in the same bar, for the same instrument.

For example, I often see a bar with some notes, a few short rests, and a full bar rest on one of the voices (think fingers on a keyboard, rather than voices). There is no reason at all to show that full bar rest. I also see bars where one finger (voice) is playing notes, leaving no gaps in the bar, but the other voice has a rest on each of those notes.

I can't imagine anyone finding that useful. Personally, I find it harder to make out the notes on the page, because someone has spilled a bag of random rests all over it, which don't belong there.

Please - make it stop!

Reply

• Dec 22, 2016 - 06:24

I can, and I will, the very next time it happens, which I'm sure will be soon - quite probably the next time I try to import anything, because that's what normally happens. It's way past my bed time though, so not today.

The max voices looks like a useful feature. I'll try that in future. Thanks.

[EDIT: Oh, I misunderstood what that's for. I want all the other parts to stay as they are. I leave them in, but just edit them so they don't show. That probably means I can't do that.]

However, although I play monophonic instruments, some of the music I find to play still has chords in it, and I leave them in, as a rule. Also, this will be happening to anyone else who imports from MIDI, at the very least, so it does need addressing.

Reply

• Jun 17, 2019 - 10:02

Hi, I know this is a very old thread but i recently started using musescore. Firstly, I would like to say it is a wonderful piece of software and I am still getting used to it. But I believe I might have encountered the same problem that is being discussed in this thread.
I used a 2nd voice to add a second line of notes to the same staff. And it added the rests right behind the whole notes for the first voice. Which makes it look messy and since I am a teacher trying to write sheet music for my students, it can cause problems explaining it in class.

I think if one of two things could happen would be great.

1st option. Have the rest appear away from the notes of the other voices.

2nd Option (More preferred). Have no rests on the same time as other notes even if the other notes are on different voices.

I have attached a picture of the issue at hand.

Attachment Size
Rests problem.png 10.77 KB

Reply

• Jun 17, 2019 - 10:33

To make the selection easier, pick a rest you can easily click.
The right-click it (Ctrl-click on Mac) and choose "Select → All Similar Elements in Staff"
Then make them invisible.

For overlapping elements use Ctrl-Click (Cmd-Click on Mac) to have MuseScore cycle between them

Reply

• Jun 17, 2019 - 13:36

If I had a dime for every person here who started writing a fugue by writing notes on a staff, then said, "hey, I need an additional voice above this", and added a second voice in voice 2, and spent the rest of his or her life flipping stems or failing to ---- and in the bass clef, you don't even have to write a fugue to start by entering the bass part, and then saying "oh, now the tenor... voice 2!" and all the stems are screwed up and fighting you the whole time.... This is, of course, not any defect of the software, but a documentation problem, that these very common cases perhaps require more explicit "louder" documentation, but I fear that people will only look at documentation as a last resort, and finding it when you need it but don't even know you need it is even a bigger problem.

Reply

• Jun 17, 2019 - 13:51

The documentation problem with the stem and voice issue is that people don't read it. If they did they would understand the voice 3 is not the same as tenor and wouldn't start entering the tenor part in voice 3 of the bass clef, then attempt to drag the voice 1 rests off the screen. Yikes! Tutorials are an attempt to overcome this shortfall, but they can only do so much.

Reply

• Jun 17, 2019 - 13:57

This is exactly right. This is a problem in the digital age where things are supposed to work without need for documentation. Cars and hand tools, and even washing machines, generally work this way, but complex software offerings do not. The classic acronym "RTFM" is growing condescending and unrealistic. But I am not ready to take the leap to "If it doesn't work the way you expect it to, then it, not you, are wrong." But this is a huge problem (for civilization, not MuseScore in specific).

Reply

• Jun 17, 2019 - 15:09

FWIW, we do have a mechanism for helping users with this - the "tours" that pop up the first time you do some particular action. Most of us experienced users disabled these long ago, but they can be quite useful for the new users.

It would actually be quite simple to add a tour that triggers when someone adds a note in voice 3 or 4 if voice 1 is empty. The tour mechanism takes care of all the details like how to display the dialog, checking whether it has already displayed that tour before or not, etc. All that is necessary is to find the right place in the code and add a call to the appropriate tour function (and of course, to write the text of the message). Just saying :-)

Reply

• Jun 17, 2019 - 20:53

Surely, it would be better if the software worked the way people intuitively expect it to work.... or had the option for dealing with it smoothly when people do that.

I still don't have a good way of dealing with extra rests in a score imported from a MIDI file, on a stave which ought to be a single voice. I've picked up some useful rules of thumb, from here, but nothing that really solves the problem.

In particular, If I select a rest, then all similar items in the stave, then delete them, I typically end up with a lot of invisible rests in voice 1 - so I leave it showing them in grey.

Reply

• Jun 17, 2019 - 20:58

Different people have different intuitions. To some it's obvious the tenor voice should be voice 1 on the bottom staff, to others it seems just as obvious it should be voice 3. Some might choose to use voice 3 for a staff for perfectly valid reasons. There's just no way to know for sure what's going on in the mind of any given user and choose different behaviors accordingly.

Reply

• Jun 17, 2019 - 22:13

So there is the swap voices command for the situation above where you've started out with voice 1 actually notating the lower voicing of a staff and adding the higher voicing in voice 2.
Once single command "fixes" that score.

As for importing midi and then deleting (although turning invisible might be better if future edits are required) all rests that aren't voice 1.
1. Range Select the staff for which you need to remove all additional rests
2. In the selection filter (F6) uncheck voice 1
3. In the inspector, press the Rests button
4. Now either mark invisible or delete
5. turn voice 1 back on in the selection filter

Perhaps not the most "smoothly" way, but hardly difficult either. At least once you know about it ;-)

[EDIT] Haha, I've just realized I posted a different way back in 2016. About equally as much effort involved though: https://musescore.org/en/node/152116#comment-620961

Reply

• Jun 18, 2019 - 06:53

So you did. This answer is preferable, because I don't want all rests invisible, and I wasn't aware of it, so I'll add that step. Thanks.

In my case, I'm never the one that allocates the notes to the particular voices - it was done by the MIDI import routine, and the pattern to it, is not immediately obvious. I've seen bars that were entirely in voice 2, for example.

I basically have to go through the whole score, one or two bars at a time, and do various little tricks to try to get it looking like a score for a single monophonic instrument, or close enough. There is no "just do this", there's only deciding which rules of thumb to apply to each bar.

On the slightly different but related topic, brought up by ekoustics104, If it's important for the voices to be in the order that voice one is the highest, etc, shouldn't there be a process for just reorganising them in that order?

By which I don't mean painstakingly slogging through the whole score doing it by hand, but selecting a command from the Edit menu, like "Exchange voice...".

It would seem to be something that could be made into an algorithm, fairly simply.

I would guess that would be regarded as separate feature request, but it that really does help with the problem I brought up too, then maybe it amounts to the same thing.

Reply

• Jun 18, 2019 - 09:55

If it's important for the voices to be in the order that voice one is the highest

Well.. usually.
This is music, so there aren't any hard rules. If a voice consistently is above another, then it makes sense to regard it as the "upper voice" of that staff and make it voice 1.

But if you're scoring for 2 instruments on the same staff (say 2 flutes), then there are likely regions where the first flute plays below the 2nd flute. In such a scenario it is important that even though the first flute now has the lower notes, they remain in voice 1 and therefor automatically have their stems point upwards.
It is the only visual clue to be able to tell which flute should be playing what notes.

The problem with MIDI import is that multiple voices are used when notes overlap (although, you can say that MuseScore should import it all in a single voice, where it'll resort to tied notes where required).
My approach would be to first fix the overlaps in notation by shortening the relevant notes. Yes, this means going over the score note by note. In case that a chord ended up in separate voices, ensure they have the same startpoint and duration. Once done, the end result is a melody spread between different voices, but without any timewise overlap between them.
Next step is to select that staff and press the voice 1 button in the toolbar.
Then select the staff again and use Tools → Implode

End result is everything in voice 1 and all other voiced rests have been removed by the implode.

Reply

• Dec 22, 2016 - 15:45

I had a feeling that was the case, which is why I made this a feature request, rather than a bug report. I also assumed other people were familiar with the problem.

As I said, I can provide examples, but it's best if I do that the next time I encounter one. As it's a "feature" to do this, I don't see that there's really a need though. I'm requesting that it becomes a feature NOT to do this - a rest should never occupy the same space as a note. It doesn't convey any useful information to show one like that, it just clutters up the page.

I'm aware that I can hide the extra rests, and then hide invisible elements, but it's hugely time consuming, and I really don't feel I should be having to do that, almost every time I import a score from MIDI.

Reply

• Dec 22, 2016 - 17:39

The behavior you request makes sense on a piano score. I simply turn the unnecessary (to the performer) rests invisible. On single note instruments such as oboe voices are used to divide the notes between musicians and the redundant rests make perfect sense to keep in.

Perhaps an "autohide rests not in voice 1" checkbox would be possible in the staff properties dialog. This would enable the composer to chose weather rests are visible in each staff. If there are a few rests you want to be visible then you can manually make them visible through the inspector. I use hidden rests from time to time for other things.

Reply

• Dec 22, 2016 - 18:02

I see. I assumed for ensembles, each instrument just got its own stave.

Making it optional seems like a good idea, yes.

The only rests I'd want to see are when there are rests in all voices at the same time, ideally, but hiding rests not in voice one would be a reasonable compromise - I'd still have to swap voices in some bars though, until none of the extra rests were in voice one.

At least that would then be enough - I already do that voice swapping stage, but at the moment, it often doesn't solve it so I have to go through the score manually hiding some of them.

On the whole, I'd prefer if it could be made fully automatic, i,e, an option that says "Auto hide rests where another voice is playing".

Reply

• Dec 22, 2016 - 19:37

Note that rests from voices other than 1 can be deleted as well. Select them and press Del if they clutter the visual space too much for you. The disadvantage only shows when then having to add a new note to a 'deleted' position for that voice, which is now harder to do.

Making all rests invisible on the other hand is something that can be done rather easy:

  1. Right-click a rest
  2. Pick Select all similar elements
    This will select all rests in the entire score.
  3. Right-click a voice 1 rest, any of the currently blue highlighted rests will do
  4. This time pick Select → More…
  5. In the dialog check Same voice in the top region and pick Remove from selection in the bottom region

Now you can either press V or Del to respectively hide or remove all other voice rests.

Of course this doesn't auto-hide them during input already, so your feature request still stands.

Reply

• Dec 23, 2016 - 00:51

In general, even for piano music, it is correct and proper to show rests for all voices in polyphonic music. If the music is not actually polyphonic but maybe happens to contain isolated passages here and there that require multiple voices to represent, it can *sometimes* be acceptable to hide *some* of the rests. The the rules for this, however, are subtle, complex, and subjective. It's extremely unlikely that MuseScore would ever be calculating this automatically to figure out which rests should be hidden and which should not. When in doubt, don't hide any rests, but if you are familiar with the rules, just go ahead and hide the ones you are confident can legitimately be hidden. It takes only a single extra keystroke - hardly "hugely time consuming".

but if you are thinking it's truly never approipriate to ever show a rest at the same time as a rest, you are very much mistaken. The cases where this *is* appropriate greatly outnumber the cases where it is not. Unless you are absolutely positive - from intimate familiarioty with the rules for this sort of thing - that your case is one of the ones in which the rests do not need to be shown, please don't assume it is OK to hide them. Not showing them can greatly complicate both sight-reading and proper interpretation, which is why the rules generally require them.

Reply

• Dec 23, 2016 - 01:26

I had a feeling I'd be told something along those lines.

It's one extra keystroke per unwanted rest, Marc. Depending on the length of the score, that can take quite a while. I'd rather be playing music than fiddling with it.

When I look at a score, I am one man, holding one instrument - e.g. a trumpet, for the sake of argument. No matter how many notes I see shown at one moment in time, I can only play one. If there's more than one, I have to pick one. That's fine. If there's a rest, I rest. If there's a note and a rest, occupying the same moment in time, I should be playing the note, therefore I don't want to be seeing the rest.

These are not complicated rules. I am a simple man, doing a relatively simple thing, in the face of unnecessary complication. What I'm asking for is more simplicity. A score that helps me play a tune, not a cluttered mess of notes and rests occupying the same moment in time, that I have to interpret, or edit down to what I actually want to see.

Reply

• Dec 23, 2016 - 01:53

It already takes takes two keystrokes to enter a rest, one more is not a big deal, especially considering that again, most of these rests *do* need to be displayed according to the rules of standard notation.

As for why the rests need to be shown, yes, you are are one man holding one instrument, but logically, you may be doing multiple things at once - playing a melody line as well as a countermelody, etc. The rests can always clarify on what beat a note enters if it enters while another voice is holding out a note. And so on and so on. There are countless places where the rests are necessary or at least extremely helpful, and that is why published music has universally shown them for basically as long as music has been published - literally for centuries. MuseScore is not in the business of inventing new rules or changing the rules of notation.

Trumpet shouldn't enter into this, BTW. Multiple voices are never needed when writing music for trumpet. They are *only* relevant when writing music for instruments that are capable of playing independent lines. And in those cases, understanding the actual independent rhythms to be played is crucial to successful playing of that music. Again, not relevant for trumpet, but vitally important for piano, guitar, etc.

Reply

• Dec 23, 2016 - 13:40

I will not normally have entered the rest myself, in this context.

It's safe to assume that the music I'm playing will not normally have been written for a trumpet. It's also safe to assume that the trumpet isn't the only instrument I'll play it on, but most likely, it will be a monophonic instrument. I favour parts that were written for monophonic instruments, but not all of them were.

The MIDI I have imported in recent times has mostly worked quite well, presumably because it's already been cleaned up a lot and isn't just an untouched live recording. There are some overlaps. at times, which don't bother me much.

However, what I mostly end up with is a part that looks like it was written monophonically, then had rests written over some of the playing notes. That doesn't help me play it - it gets in the way. What I'm asking for is an option to automatically hide those extra rests, so I don't have to spend time doing it manually.

Maybe a plug in could do it? I'm not clear how powerful the plug in system is.

Reply

• Dec 23, 2016 - 14:06

If it's a monophonic instrument, there should be only a single voice. If you are seeing multiple voices, that's a flaw in the MIDI file - there are apparently overlapping notes, unplayable on that instrument. But the solution isn't to hide the rests, it's to fix the file. Either using a MIDI editor, or just tell MuseScore on import to use only a single voice, so there are no multiple voice.

Stated plainly: a correctly imported MIDI file for a monophonic instrument will have no extra rests. if you have a MIDI file that is giving you problems even after using the import panel to specify you want only a single voice, please attach it so we can see what you are talking about and advise you on how to fix it.

EDIT: If the file was not created for a monophonic instrument, then rests are the least of your problems - there will be all sorts of multiple *notes* at once you can't play. Deleting all but voice 1, then maybe using the explode function to isolate the top notes of chords, would be one way to address that. And again, hiding rests won't be part of that process.

Reply

• Dec 23, 2016 - 14:32

Somehow you seem still under the impression that hiding/removing all these rests is a lot of work. Using the method given above, it is a total of 7 mouse clicks and 1 keystroke and all non-voice-1 rests are gone.

Somehow also, using the correct import settings for the melody (max voices to 1) seems also not be your solution.

But yes, one could write a plugin that uses your specific rules for hiding rests.

Reply

• Dec 23, 2016 - 16:15

Okay, the reasons for not setting the number of voices to one when importing, include but are not necessarily limited to the following:

a) Where there are overlapping notes, I want to make the decision which to play. I don't want to leave that to the import routine. I may or may not edit those out, depending on how much they distract me.

b) The music might contain some chords, in which case I may well want to keep them in, for reference. I don't claim to be a jazz musician, but they are familiar with the concept of improvising over chords. Taking the chords away may remove information I'd rather keep - I might not play the same notes each time I play it, or I might play the root note when I play it on one instrument, but a different note when I play it on another. If I did want one note instead of a chord, I would edit that myself, and I wouldn't want the import routine to make the decision for me.

The thing is, Marc, this is a feature request, not a bug report. I'm saying I would like this feature. Telling me I shouldn't want it is not really the response I'm looking for. I accept there are other ways to do it, but none that just involve selecting an option from a menu, which is what I'm requesting.

Okay, I'll look into the whole plugin thing. I've been put off them a little by having MuseScore crash when I tried some of them. I guess it's down to version dependency, so it may need rewriting after a major revision of MuseScore.

FWIW, here's an example of the sort of thing I'm talking about:

Carpenters - Desperado (G,Em) - flute.mscz

There's a small backing group, hidden by editing the instruments and unticking them. This is a guitar part, technically, so it's entitled to have all of the above - overlapping notes and chords, but is mostly monophonic. Notice, for example, the full bar rests in many non-empty bars.

I could have limited the voices to one, but then I'd lose sight of the odd two note chords, which I like to keep for reference - I do also own guitars but they're not among my main instruments - I often forget which end to blow into. On the overlapping notes, I don't have a problem leaving it like that, but I would have a problem if the import had chosen the "wrong" one for me.

I'm not a robot - I don't need the sheet music to exactly correspond to how I'll play it, but I do want it to be as clear as it reasonably can be, with the least amount of effort for each new tune. I'm not a composer, or an arranger, though as I think you once pointed out, I do arrange. I do it for the same reason I unblock sinks - because I want it done, not because it's my trade or my hobby.

Reply

• Dec 24, 2016 - 07:54

It's better? Okay. So we go back to the start of the thread! :)
From the Midi file, select only the content of the Guitar staff, and then in the Import panel, select only one voice to that staff. Apply.

one voice.jpg
Then, change the instrument (for a flute), change the clef (treble), untick "visible" other staves. I arrives here: 4Carpenters - Desperado.mscz Then, it remains some editing work for finalize.

EDIT: after this editing work for clean out some notes (really not a big deal now, just a few little minutes, it's done), you get: Carpenters 1- Desperado.mscz

- With the previous score, I had simply created a part, before exporting it in Midi format, apply one single voice, then reintroduce into the score, and copy-paste onto the former staff.

Reply

• Dec 24, 2016 - 13:01

Thanks. Yes, it's certainly a method to try, though it clearly can cause problems of its own.

For example, the original bar 12 made sense to me if I just hid the extra rests. I could see there was just an overlap of notes - the A string is left ringing when he plucks the G string. It might have been intentional, or it might just be one of those things that happens in guitar playing - a bass player would normally try to mute the string he'd finished with, but a guitar player wouldn't necessarily bother.

So, if I wanted to make it clearer, I'd probably edit that so the A ended just before the G started. More likely, I'd just leave it as it is because it's clear enough and it suggests options on how to play it - e.g. taking a breath instead of playing the G, or even skipping the A.

After letting the import routine decide what to do, it becomes a bit of a mess :) Without referring back to the original, it's quite hard to see what was intended.

But, yes, for now, that is one of the ways of doing it, and for many tunes it might be enough. On the whole, I'd rather just have a way to hide all or most of the extra rests, or collapse it to one voice, but leave any bits that are ambiguous, as they are.

Reply

• Dec 24, 2016 - 14:08

"After letting the import routine decide what to do, it becomes a bit of a mess"

It does not become a mess. This measure is already an (enormouss) mess in this MIDI file. See.
mess measure.jpg
Be fully aware, as has been said, that the MIDI format is not really the most appropriate to get a clean result immediately. You must make an editing work somewhere. Personally, I do not remember a Midi file that would have required no intervention after import.
I've seen worse than this file, which ultimately is not so bad, if not rather good!

"Without referring back to the original, it's quite hard to see what was intended."
Why not. Is it really so difficult to do that? I don't think so.

Recall also that you can select a maximum of two voices (instead of one) in the Import panel (for the staff, or measures)
Like this. No sure here that change is a better idea.
two voices.jpg
It all depends on the file. Look, try (one or two voices), and at the end, a little cleaning, and all will be well.

Reply

• Dec 27, 2016 - 02:44

I like the colourful pictures :)

As you say, it all depends on the file - one method works better for some than others. The way the import turned a simple overlap of two notes on a guitar (which is very common) into a sequence of rapidly alternating notes, is entertaining, but not what I'd want.

Switching between two tabs or windows, to compare two files and pick bits from each one, is a bit too much like hard work for me - I'll do if it if it has to be done, but it's not my idea of fun.

The file is quite good, yes. Many of them are, from the site I got it from... I don't suppose it's appropriate to post links, so I won't. I don't know if there's a pm system here either, but if there is, feel free to ask me where I got them.

I picked this one because it shows each of the main problems, but not too many times, and in a fairly clean and simple score. I come across worse examples, of course, and longish scores with the same problems many times over.

When you first asked for an example it was about 6 am, here, and I hadn't got around to going to bed yet, due mostly to fiddling with and cursing my computer - hence the slight delay in "finally" posting this one, as Marc put it. I couldn't post examples I'd seen before, because I'd already fixed them. I could post more, as I find them, but I think this case pretty much covers it - only imagine the same problems four or five times over, in a longer score.

It seems an automated process is possible, so that's the feature request I'm making. I fully understand there may be a reluctance to spend time implementing it, but I do feel it would be a useful feature - to other people, not just to me.

I'll see if I can wrap my head around plug in writing. Maybe that's a way of doing it. There does seem to be an inherent lack of stability in plug ins though - some that presumably once worked, now caused an instant freeze or crash, when I tried them. That does put me off, a little.

Reply

• Dec 23, 2016 - 20:23

Thanks for providing the example; now finally we can begin to understand where you are coming from. This piece is indeed a bad mess, which really reinforces my point. In the normal course of music, it is definitely *not* generally appropriate to hide rests in multiple voices just because they happen to overlap notes. You are wanting to do that only here not because it is correct musically, but because the piece is in such bad shape voice-wise that hiding rests would mask some of those obvious errors and produce something that at least *looks* like monophonic music even though it clearly still isn't.

As I've suggested, this is not really a good idea, and the score you posted provides several excellent examples of why. Consider measure 7, for example. If you simply hide rests to make it appear like this is monophonic, you end up with a measure that apparently contains 4.75 beats (count them!) and it is not at all apparent what the actual intended rhythm is. The "A" that is actually on beat 2.5 would appear to be on beat 3, the sixteenth note that is actually on beat 3.25 would appear to be on 4, etc. That's because a couple of the notes overlap, with a voice 1 note starting before a voice 2 note finishes. Without the rests there is absolutely no way to know where this happening, meaning that attempting to play it would yield all sorts of train wrecks rhythmically. The results would be quite a bit worse than trying to read what's there- the rests give you the necessary cues as to where the overlaps occur.

So while I do understand where you are coming from, hopefully you understand where I am coming from as well. Hiding the rests is definitely *not* the solution here - actually fixing the score to get everything into one voice is. Once you do that, then you can remove the contents of voice 2 safely.

As it is, getting that measure fixed is not overly difficult. Simply change the voice 2 "E" on beat 2 to an eighth, then change the dotted quarter "A" on beat 3 to a quarter. Now you can select the measure and press the voice 1 button to merge. Similar process for other measures containing overlapping notes - shorten them so they don't overlap, then merge. Yes, it's a pain to go through an entire score and do this, but you are the one who chose this task :-)

Again, though, rather than trying to mask the issue by hiding rests while leaving the overlaps in places, better is to simplify the process of fixing the problem for real - collapsing polyphonic music into a single voice. So I could imagine a "smart implode" facility that attempted to do exactly what I described above - shortening notes anywhere needed to allow them to be merged into a single voice, then merge them, then finally remove the now truly unneeded rests. Something like that would be a better use of development effort than a "hide certain rests to partially mask certain problems in messed up scores but actually make things rather worse" option.

Meanwhile, as for what to do with this score or others like it, personally, I'd probably import the MIDI it twice, once with voices limited to 1, once with it at 2. Then find the portions of the latter that are needed and copy/paste them into the former. That's likely to be less work than how you are doing it, but then, I still haven't seen the original MIDI, so I'm just guessing here.

Reply

• Dec 23, 2016 - 20:59

A smart implode would be great, and quite possibly better, provided it didn't try to condense chords to a single note, and decide for me which one it should be - the same goes for overlaps, though I can think of a reasonable rule for that one - I'd generally rather write the note that started second, if the first is a continuation of another note, with a tie.

I'm not really aiming to completely "fix" a score though, I'm just aiming to make it reasonably clear. If the rhythm, as written, goes a little bit off, I'm not even likely to notice, because I'm really going by the tune that's in my head, most of the time, and using the sheet music to help me remember the note values. It's nice if it's correct enough for MuseScore to play it to me roughly how it should sound, but that's not my main use. Most of the time, I will just be looking at it on the screen as though it was printed out.

FWIW, here's the original MIDI track for this example:

Carpenters - Desperado.mid

At the stage where I uploaded the MuseScore file for it, all I'd done was import it, hide the other parts, and change the instrument to a flute... then apply a style to fit as much of it as I reasonably could on my monitor at once.

Reply

• Dec 27, 2016 - 02:27

Sorry, I lost track of who said what, and when, in this discussion - partly due to the non-linear nature of the threads in this forum. I don't think I replied properly, to this post.

What you said is true, but due to the nature of the MIDI import process, the extra rests can be in any voice. so I still have to manually hide them, if they're in voice one, or try swapping voices in certain bars, then deleting rests again, but that doesn't always help much.

Reply

• Dec 27, 2016 - 19:47

Yes, and given that the example you showed contains many cases where the rests *cannot* bne hidden without resulting in totally incorrect notation - measure with wrong rhythms and too many beats because the overlaps are no longer apparent - this just underscores why hiding rests is *not* the right solution., Merging everything into a single voice is. Anything else is just work expended making things worse.

Reply

• Dec 23, 2016 - 01:45

A common problem with MIDI is that ones recorded from live performance are seldom quantized meaningfully, so you end up with all sorts of uses of multiple voices that should not be there. Eg, places where the notes of a chord are not quite all played or released simultaneously, resulting in multiple voices being used to represent the slightly different start and end times for the individual notes of the chord. Hiding the resulting rests would definitely *not* be the right solution in most of these cases - instead, the rhythms themselves should be quantized / simplifed to remove the need for the multiple voices in the first place. The chord should be written as a simple chord, not a series of overlapping multiple voices or slightly different start and end points. And if this is done, the whole question of hiding rests becomes moot. In general, importing MIDI files requires a lot of this sort of cleanup if the MIDI file represents a live performance, which is one reason MIDI import is often less efficient than regular note input as a method of entering scores.

Reply

Do you still have an unanswered question? Please log in first to post your question.