folder export to XML

[mmike]

Since the Dolet 7 plug-in (32-bit for up to Fin 2014.5) doesn't work anymore in Fin27.1, I am using the Finale Export feature, which seems to work fine for individual files, but the Translate Folder to MusicXML option (which certainly used to make it less tedious with many files to convert) does not work. Anyone experience this? Is this now broken?

[musicxml]

What do you mean by "doesn't work anymore"? It should be working fine. If you don't have any Finale files in the selected folder, it just does nothing rather than giving you a message. And it won't work if your 30-day trial has expired. If those aren't the issues, it may be best to contact Finale support.

[mmike]

What do you mean by "doesn't work anymore"?

What I've said ... exporting individual files works fine. Exporting via Tranlate Folder to Music XML brings up a screen asking for a directory, which I choose (and which has a number of musx files in it), I then say OK which brings up the attached screen. If I say Yes (and there are no xml files in the directory) nothing happens, no xml files are created. If I say No nothing happens either (as expected).The XML preferences are set to XML 4.0, compressed (which works just fine with individual files, but I have also tried some of the other settings there, to no avail). Finale Tech Support has not come up with any solutions, other than suggesting re-creating the Finale references, which I did, and which did not change anything. This feature, at least on my computer, does not work (ASUS laptop, Windows 10 Pro, Finale 27.1, recently purchased and installed- not a trial). It did work on my previous installation (Finale 2014.5), but there, I think, it was still using the Dolet plug-in.

[musicxml]

Thanks for this information! I've been in touch with support to see if we can figure out what is going on here and get this fixed.

[mmike]

To update - I have been discussing this with Finale Support, who have so far not come up with a solution (and no, recreating your preferences does nothing here). However .... In Finale scripts there exists a script under Batch Process > Batch Export Music XML, and that works! You have to set the source and destination folders first in Finale Script Options. It converts all files in the chosen folder to the settings you have made in Export > MusicXML Preferences.
Of course by now I've done what I had to do by converting files individually, but it's nevertheless good to know. Why it doesn't work from the Export menu (as it is intended to) is still a mystery, though.

[musicxml]

I'm glad you found that the script works, and apologize for the inconvenience.

This still seems really strange though and would be good to identify and fix. When you used the script, did you set the destination folder to something different than the source folder? In the menu item those are the same thing. Might there have been networked storage involved somewhere vs. local storage?

[motet]

-

[mmike]

When you used the script, did you set the destination folder to something different than the source folder? In the menu item those are the same thing. Might there have been networked storage involved somewhere vs. local storage?

I did both - if you deselect a choice for a destination, then it goes into the same folder as the source, or on the other hand you can choose any other folder where you want the newly create xml files to go. I use no networked storage of any kind.
By the way - something I've asked myself for a long time - why in the world have MusicXML files an .mxl extension? (seems to me an extremely confusing choice)

[mmike]

yet more - this might be the answer to it all: the File > Export > Translate XML feature is apparently tied in with whatever there is selected in the Finale Script Options. I have deselected everything there (no source or destination folder chosen), and now the Translate feature works as it should, putting the xml files into the same directory. Beats me, though, why there was something in these Script Options (this is a new install of Fin27 and I hadn't at all used any Finale scripts ...)
By the way, using the Finale Script, it actually opens every single .mus file in that folder while translating them ... which doesn't happen by doing it the other way.

[musicxml]

It works on most systems but not on others, and it's unclear what causes the difference. It seems unlikely it has to do with FinaleScript setting, but we'll see. It appears to be a Windows-only issue.

We used to use .xml for the MusicXML file extension, but that got confusing with so many different types of XML files out there. Starting with MusicXML 3.1, the default extension is .musicxml for uncompressed text files. The .mxl extension is for compressed files that can include images and linked parts.

[mmike]

It works on most systems but not on others, and it's unclear what causes the difference.

Tested it some more and now it doesn't work again, it's simply unpredictable. Best (at least in my case anway) to do individual exports.

the default extension is .musicxml for uncompressed text files. The .mxl extension is for compressed files

To export and share normal scores (no images, but any size up to symphony orchestra layouts), what is actually the best method to use? Is there a difference (other than including linked parts in compressed files) regarding quality and details when importing them again?

[musicxml]

Thank you so much for your patience on this. I think we have figured out the problem. MusicXML batch export was relying on the presence of short 8.3 file names on Windows to search for all the .mus and .musx files together in a folder. However, some newer PCs don't use short 8.3 file names, so this no longer works on those systems. It would only work if you have a folder with .mus files rather than .musx files.

Does this match what you are seeing? This should be fixed in a future Finale v27 update.

The .mxl files are best in most situations because they contain any shapes from the shape designer, as well as the linked parts. Plus the files are a lot smaller.

[mmike]

Thank you so much for your patience on this

ditto

It would only work if you have a folder with .mus files rather than .musx files.

Indeed - I tested this and it does work.

The .mxl files are best in most situations

Good to know, it's what I have always used. One small thing I have noticed - although the Finale files are by now (XML4.0) quite well translated to XML (and back), the enclosures shapes around a tempo marking (and some text boxes) are always missing in the re-imported versions (which they aren't, for instance, for rehearsal marks. measure numbers, expressions). Something basic to fix?

[musicxml]

I have also replied in the Finale community forum with an update on this issue.

The metronome enclosure problem is alas an oversight in the MusicXML definition, so it will need to be added to a future version of the MusicXML format. I have added an issue for this at https://github.com/w3c/musicxml/issues/448.

For the text boxes, we would need to see a sample Finale file. It might be best to open a new Finale support case for that, as it is a separate issue from the folder export. Thanks!

[mmike]

Translate Folder to MusicXML now works in Finale 27.2, but it looks like it just invokes the Finale Script Batch Export feature, as I had noted before

using the Finale Script, it actually opens every single .mus file in that folder while translating them.

If one transates a folder with many files in it, that's a lot of open Finale files. Is that really intentional or, rather, necessary?

[musicxml]

It's not invoking the FinaleScript batch export feature, but it is doing something similar. You have to have a Finale file open to export it, so yes, there will be a lot of Finale files opened during the process in large folders. Each file should close after its export finishes.

[mmike]

Right you are. I tested Translate Folder to MusicXML again and all files in a folder (any chosen folder, actually, not necessarily the folder of the one open file) get translated and are closed. Great! Works perfectly now. (I guess for some reason I had assumed it invoked the Finale batch script, where the files indeed stay open - sorry)