Bar-position shifts
There is another problem I came across: bar-position shifts due to import of a misinterpreted MIDI file (or, an oversight of 'spelling' by the user).
Anyway, I wrote the file below(.._BAD), and wanted to write a plugin to change it to (.._GOOD). Well, I started, created newScore and a few shifts in JS, but I found it very slow.
So I cheated, a wrote a Delphi program that compiled and converted the original msfile in less than a quarter of a second.
I want to continue the project with three more pieces: to include a crotchet and a quaver anacrusis (pickup or upbeat) start and a minim on the (target) second beat - (that is a third beat note tied-over to the first beat of the next bar in the ..._BAD version).
The Delphi program opens the source file, scans and copies the notes and the rests to a transitional file. Then it opens the transitional file recalculates, adds the ' bits and copies them to the target file. Any idea, how I can do the same in js? Where can I read about it?
| Attachment | Size |
|---|---|
| origStraight_Bad.mscx | 5.59 KB |
| shiftedStraight_Good.mscx | 5.55 KB |
Comments
I don't have advice about JavaScript but just in case you weren't aware it is possible to do the shift manually using copy and paste .
In reply to I don't have advice about by David Bolton
David, your advice works in such a short piece. I will also test it with my second test-piece (the same as this one, but with and added instrument starting its melody with an anacrusis -wrongly- in place of the presently first crotchet rest). Your 2nd step does not select the whole voice - only the given staff within the given page. The copy and paste puts the notes to their intended place for a few bars only, afterwards, the shift "comes back" (most probably due to the persistent positions of the "< /measure-measure=... >" lines within in the .mscx file).
This problem prompted an earlier RFE idea Macros, a long shot - in response to which, lasconic suggested, I should rather think in terms of a plugin. That I tried, wrote a short (extendible) test piece and - lacking the knowledge of how I could quickly edit the .mscx file direclty within the plugin, I emulated the solution by a quick Delphi program. (The exercise was very useful, I understand more of the .mscx files now.)
I still hope I'll find a way to introduce a reliable plugin (or a way to write a callable external routine) to solve this trivial problem. Especially with the view of many a beginner starting their piece with an anacrusis, but -wrongly- on the first beat of the bar......
In reply to David, your advice works In by drikanb
"Your 2nd step does not select the whole voice - only the given staff within the given page."
If you select the first note, top staff in the first step and the last note (of the piece), bottom staff in the second step then it should select all the notes. It does for me.
In reply to "Your 2nd step does not by David Bolton
David, how many instruments and pages did you try? If it works for you, why does it not for me (0.9.5 on WindowsXP)? I don'use my 0.9.5 LINUX version (Ubuntu 9.10 ) for experiments, as it crashes on -even the 'official' - plugins.
And, how can you jump to the end of a 29-page 10-stave score without losing the selection? (shift+end / ctr+shift+end does not do it - I tried it backwards too - starting from the last note)? Navigator is cumbersome and often refuses to slide beyond a point (after the the first and/or before the last page).
In reply to David, how many instruments by drikanb
Make sure you are following the instructions carefully. I added an extra couple steps to emphasize that you don't need to be pressing shift+end or ctr+shift+end.
In reply to Make sure you are following by David Bolton
David, points 1-3 were very useful. After all, it needs attention for an old dog to learn new tricks (or, rather, un-learn some old ones). Navigation in this way is, indeed, very easy.
However, having pasted the block (copied from the second beat of the original file) to the first beat only worked for the first two bars (see the score details below). The third bar started with a (n extra) rest - exactly in the way, as was in the original file.
I opened my score from a file that was originally imported from MIDI then saved back; and later, had the track name, instrument name and MIDI program number changed manually in the .mscx file, opened, replayed and saved back.
The fact that the block copy worked for the first bar suggests that only the notes and rests were copied and pasted back one beat.
But the fact that the from the third bar the clock paste reverted to the original state suggests that not only were the notes and rests copied but the '< /measure - measure number=" >' lines too.
Before I could conclude whether my assumption arising from this contradiction was right (thus there is a bug) or wrong, I wanted to have proof, by searching for a testable example - produced entirely in MuseScore (I haven' found such in the forum 'Made with MuseScore'). Do you happen to have such a file that I could test?
In reply to David, points 1-3 were very by drikanb
Just to avoid misunderstanding (sorry if I'm just telling you things you already know), MuseScore does not really move <measure> lines.
When you open a score in MuseScore the whole file is read and each piece of xml is used to fill objects in memory. Then the file is no more used.
When you used the UI, you change the data in the objects (and not the file) and when you save a file, each memory object is used to recreate an new xml file bundled in the mscz file.
In reply to Just to avoid by [DELETED] 5
lasconic, thanks for the clarification, I would appreciate lots of similar info because my knowledge has huge gaps. If my question was not clear, let me expand on what I meant by using the expression 'moving'. I don't know the mechanism of 'copy and paste' in MuseScore, as it may be: 1) when I mark the notes/rests for 3 bars' worth (but starting from the second beat of the first bar spanning to the first beat of the fourth bar), wwould the program put the barlines to their appropriate places (in other words, would the 'paste' action emulate as if I put in a lot of notes and rests in manually and then the siftware would automatically generate the < /measure> then the lines to the flow)? Or, alternatively, 2.) the marking (selection for copying) includes the < /measure> then the lines - associated with the last note of the bar in the original file (and therefore, at some point, the bars - after inserting an extra beat rest - would revert to their original bar positions)? This latter was that I meant by 'moving' .... I think, my first example-pair may illustrate the jist of my query. (then we could look into the matter of anacrusis too...)
Obviously, I am aware of the fact that the files only come into the picture at the times of loading and of saving.
Is UI short for user Interface? (The copy and paste In this case?) My query was about that - Obviously I didn't expect a wrong file (in memory) to recover itself by saving (to file). Not even by a restart of Windows....
In reply to lasconic, thanks for the by drikanb
"let me expand on what I meant by using the expression 'moving'..."
It is neither 1 or 2. The bar lines do not move and they are not copied/pasted. When you use copy a selection it copies the notes, rests (and a few other things such as lyrics if present). It fits these notes in to the existing measures.
In reply to David, points 1-3 were very by drikanb
You could share the file you are having trouble with. I haven't had any problems myself. I'm not sure what type of file you are looking for but there are a few demos scores in the MuseScore program folder.
In reply to You could share the file you by David Bolton
All right David, I - reluctantly - attach the messy file. (Obviously I have a proper form too that I produced in Sibelius back in 1992). Please, regard the score as one that was imported from an earlier MIDI version only in order to test MuseScore (hence the lack of pizz.-arco changes; the messy MIDI distribution of the horn-clarinet-piccolo lines into 2 channels, the wrong quantization of triplets into two-note+1-note quaver pairs towards the end of the score etc.)
Before attaching it, I tried to shift the whole score one beat back using your suggestion, several times. I ask you again to prove me wrong. (Practical tip: before marking the block, insert a dummy note to the piccolo line, on the second beat of the first bar. After the paste, you can delete that dummy note).
There is another strange thing: although the notation does weird things, the MIDI keeps playing without the (wrongly re-inserted) rests in the score (so the sound flow is alright, whilst the notation is wrong).
I wonder, whether you will be more successful with the shifting. If so, could you attach the shifted file?
(Manipulating the file -outside MuseScore is cheating - by doing that I could already solve it)
In reply to All right David, I - by drikanb
It looks like a MIDI import bug.
The problem is all the measure that should have full-measure rests actually only have half-beat rests which is short one beat. Do you have the original MIDI file.
In reply to It looks like a MIDI import by David Bolton
Yes I have the original MIDI file.
'The problem is all the measure that should have full-measure rests actually only have half-beat rests which is short one beat'. I tried to understand this sentence, and even allowing that you might have meant half-note rest, it is not what happens - after all, there are extra beats' worth of rests, rather than being short of beats.
However, while I was trying to interpret the above assumption (and pondering why should have full measure rests), I thought, the bug may be in the rule of having the long(minim) rest first, followed by the short (crotchet) rest. Since the algorythm I use in the external Delphi file manipulation program adds up the < ticklen values > and when it adds up to the bar length constant (1440 ticks - in this case), then it inserts the < /Measure > line. It is possible that there are overlaps of rests. E.g.: crotchet rest(480), crotchet rest(480), minim rest(960) - and themeasure should finish in the middle of that last minim.
I tested it by making all the rests crotchet rest in the first few bars (before the copy-paste) - but the offset reverted in bar three. However, instead of discarding the file, I pressed the replay - and, to my greatest surprise, towards the last third of the score, the bars turned round again, and the trumpet started its tune on the upbeat, as it should.
It'll take me a while to experiment with different files - but I shall return to you when I have the answer - or further questions.
.
In reply to Yes I have the original MIDI by drikanb
Yes, I meant half-note rests. I don't see any measures with extra beats. See screenshot attached (score opened using r. 2776 nightly, Windows 7)
In reply to Yes, I meant half-note rests. by David Bolton
The plot thickens! Your system seems to display the score differently; as opposed to 'your' minim rest on the left side of the bar, 'mine' shows whole measure rests - horizontally centered. Did you test, whether it is only the appearance, or it also behaves like a minim rest (for instance, did you try to break them into crotchet rests)?
Here is a section of the actual .mscx file (of the first bar of the piccolo staff):
< Staff id="1">
< Measure number="1">
...........................
< Rest>
< ticklen>1440< /ticklen>
< durationType>half< /durationType>
< /Rest>
< /Measure>
< Measure number="2">
The contradiction appears to be between the ticklen value of 1440 (that, when I successfully changed into 3 rests of 480 ticklens each - as I described it in my earlier comment - forced the display into three crotchet rest symbols per measure) and the durationType=half. I'll have to test whether this value is the 'graphical' name of the whole measure rest, or the or 'logical' name of ticklen 960. Although ticklen is a MIDI unit, its use descripts the rhythmical value of the notes - regardless of their being played or not. See below: V'cello 3rd bar, where there is a minim rest and a crotchet note. (There is no durationType - but it appears that a MIDI sync value is included in most parts ("ítick> somenumber )
< Measure number="3">
< Rest>
< ticklen>960< /ticklen>
< /Rest>
< Chord>
< ticklen>480< /ticklen>
< tick>3840< / tick >
Did you try the mark-copy-paste process on the score as you earlier advised? Because there is the extra beat (in notation and not in the sound): in Bars 1 & 2, the bass plays on the downbeat - from the third bar it reverts back to crotchet rest in all instruments (the extra beat) on the 'one', bass crotchet note on the '"two"', (bass)crotchet rest on the '"three"' / / barline / / exactly as started in the original version.......
In reply to The plot thickens! Your by drikanb
"Your system seems to display the score differently"
I was using the latest nightly build. Maybe you are using a different version of MuseScore
'Did you try the mark-copy-paste process on the score...?"
Yes I tried it and it didn't work with this file, but as I mentioned previously, the source of the problems is MIDI import (or possibly a faulty MIDI file). It you have an interest in seeing this bug fixed you might want to share the original MIDI file.
In reply to "Your system seems to display by David Bolton
Although I know the difference between stable, prerelease and nightly - I have no information on how I can download/install the nightlies. (Therefore I only use the 'one-click' 0.9.5 stable download - but would be interested in fresher versions)
I did some analysis of the file since my last comment and I found that:
'< durationType>half< /durationType>' was, indeed only a graphic script as I assumed (when I deleted all such lines, the whole-measure bar rests turned into dotted half rests)
and also that
< tick>somenumber< / tick > was probably a MIDI sync message with no control function on notation - hence nor on copy-paste (as, when I deleted all such lines, it had no effect either on the notation or on the sound.
If there is a bug, I definitely 'have an interest in seeing this bug fixed' - (not in having the score correctly re-spelled) - after all, I want to know the ins and outs of MuseScore.
In reply to Although I know the by drikanb
If you want to know more about how MuseScore handles midi import, a place to start could be the importmidi.cpp file.
As you are a delphi programmer I assume you can read and understand C++ code.
MuseScore is great because you have access to the code and so you don't need to reverse engineer the file format! You can see in the code how it is used!
If you didn't yet, you can check out MuseScore code with a standard SVN client.
Nightly and prereleases are one click install too on windows. You can find them here. There are for testing purpose only
In reply to Yes I have the original MIDI by drikanb
Could you attach the original MIDI file?
Here are the original and the shifted scores of the second type. Here the melody started with an up-beat (pickup) note wrongly written as the downbeat (first beat) of the main body. The second score is correctly spelled (that was not difficult with Delfi, directly editing the .msx file). The only cheat I made in this score was that MIDI would have played 3 beats in the last bar (instead of 2Í) and I set "the actual duration" of the last bar in the measure properties of MuseScore.
I haven't found the location of this parmeter yet - I will have to go through the .msx file - UNLESS ONE OF YOU TELLS ME WHERE THESE PARAMETERS ARE LOCATED WITHIN THE .mscx FILE.
In reply to Here are the original and the by drikanb
The attachments above were from work in progress by mistake.
THE RIGHT ATTACHMENTS ARE HERE
apologies....
In reply to Here are the original and the by drikanb
The only cheat I made in this score was that MIDI would have played 3 beats in the last bar (instead of 2Í) and I set "the actual duration" of the last bar in the measure properties of MuseScore.
You'll have to look at the source file to find the property, I've not edited the mscx file for this before.
In reply to The only cheat I made in this by David Bolton
David, my question you replied was:
'I haven't found the location of this parmeter yet - I will have to go through the .msx file - UNLESS ONE OF YOU TELLS ME WHERE THESE PARAMETERS ARE LOCATED WITHIN THE .mscx FILE.'