Problems with capella files
When you open capella files with museScore you will encounter several issues. So far I have encountered three.
If you have created a system of, say, soprano-alto-tenor-bass, with capella and you open the file with museScore, the notes of the tenor line are all transposed up one octave compared to the original although museScore shows the right key.
In addition, it is impossible to create a "Start repeat" at the beginning of a system. The line is only shown in the first line of the system. If the file was created with museScore from scratch there is no problem at all.
Also, museScore don't recognizes the number of lines a system has when the piece of music was created first with capella. You will clearly see this when you use the mixer (F10) with the attached example.
If you use museScore from scratch you can use the mixer and all parts of the piece are shown correctly. So you can mute certain parts of the file.
Attachment | Size |
---|---|
Example.mscz | 8.09 KB |
Comments
Could you attach the Capella file too?
Can't Capella export as XML (I believe newer version can) and how does that import in MuseScore?
What MuseScore version and Operating System are you using?
Hi there,
first of all, capella is capable of exporting cap-files as xml.
Attached you will find a xml-file which was created by using the export function of capella and the corresponding cap-file as a zip-file. Otherwise I could not have uploaded it.
To me it seems as if museScore is capable of treating only the xml-file correctly.
I use Windows XP, SP 3 and capella 2008.
I can't get to either attachment.
Which version of MuseScore?
Edit: I can get at
http://musescore.org/sites/musescore.org/files/issues/Example%20xml-fil…
and
http://musescore.org/sites/musescore.org/files/issues/Example%20capella…
gizzmo456, what version of MuseScore are you using?
I use version 1.2.
Are you able to reproduce in the nightly builds?
The latest nightly crashes on opening the capella file
I've just found a bunch of files that crash on import in a recent nightly build, cbd68b8
They all start with a start repeat bar line, this seems to be the common denominator and cause of the crash
gizzmo456's .cap file though now seems to import without crashing, but still has the transpose/octave as well as the multi-sfaff problem.
Do we need to split this issue into several?
a) importing tenor staff one octave to high
b) capella import doesn't recognize number of sfaffes per system and creates one multi staff instrument instead.
c) crash on capells import, if that begins with a start repeat (regression vs. 1.x)
d) loses start repeat bars (if not the first, in wihc case it crashes, see cc) abobe. 1.3 loses them all)
e) loses end bar
Yes, it would be better to split this issue. Also creating a small example for each issue would help to fix the bugs.
Problem with that: I don't have Capella, just read only versions (Reader and Demo). But lots of Capella files that fail, though I can't really share them, due to copyright.
f) ties and slurs get lost
I'll try to get some sample files, if and when I do, I'll create separate issues for each
Links to failing files on public download sites such as hausmusik.ch would help too, although smaller files that demonstrate issues make debugging easier.
I don't have Capella either. I did download and import a number of capx files from hausmusik into MuseScore, but did not find any crashes.
The very fist score on hausmusik.ch I looked at (//www.hausmusik.ch/notenregal/a/aguado_dionisio(1788-1847)/tanz_d-dur/ ) shows the wrong octave problem, when importing the .cap file. The .capx doesn't have that issue (but others, I guess known restrictions, no slurs for example)
Another one (//www.hausmusik.ch/notenregal/a/ahle_johann-rudolf(1625-1673)/jesu_meines_%20herzens_%20freud/ ) show the losing ties problem (no .capx here). Other ties (from some other scores) have got imported though.
Same score also shows the lose end bar problem.
Another one (//www.hausmusik.ch/notenregal/z/zelter/chor/bundeslied/ ) shows the single instrument with multiple staves problem in both cap and capx import as well as the wrong octave problem in cap import, the lose end bar and the lose tie problem. Fermatas are lost too, as is the title.
All in all I wouldn't really call this 'imports Capella files fairly accuratly' like the handbook claims.... esp. as 1.x import is even worse.
Voltas are lost too
Some small files to illustrate the problems described above (created with Capella 7). Note that Capx import is different from Cap import for the number of beats in the first measure.
Hmm, tie.cap works in 1.3 and 6d6d73d, so my report was wrong. Guess in the cap file I imported they really were slurs but should have been ties.
slur.cap works in 1.3 but not in 6d6d73d, so it is a regression.
other than that, yes, these show the behavoir I described.
SATB shows an additional problem with several vertical frames, 2 containing nothing but a #. Strangly with 1.3 vs. 6d6d73d in a different order.
Thanks for the detailed information. I will investigate the issues. May take some time, as I am rather busy right now.
As I could not find the split issues (see reply #12) yet, I have created them myself:
#20891: [Capella import] Importing tenor staff one octave too high
#20892: [Capella import] Capella import doesn't recognize number of staves per system and creates one multi staff instrument instead.
#20893: [Capella import] Crash on capella import, if that begins with a start repeat (regression vs. 1.x)
#20894: [Capella import] Loses start repeat bars (if not the first, in which case it crashes)
#20895: [Capella import] Loses end bar
#20896: [Capella import] Ties and slurs get lost
Thanks, I hadn't got around creating those issues. Special thanks for having allmost all of them fixed now!
Here's another (mentioned above):
g) lasconic's SATB.cap shows an additional problem with several vertical frames, 2 containing nothing but a #.
created an issue now: #20911: [Capella import] file with title results in several vertical frames, 2 containing nothing but a #
Will close this issue with status "duplicate", as separate issues now have been submitted for the various problems, and no commit in GitHub refers to (or will refer to) issue 14438.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.