This was a deliberate design decision of the language. Not only is git not particularly good with very large files (it certainly wasn't back then), diffing and merging files where several hundreds of millions of lines jump around arbitrarily is practically impossible. In reality the files were several gigabytes and for most of them the ordering of the lines was insignificant. Many years ago I worked with a FORTRAN derived file format which from the outset should be ideal for git. XML files are often of that kind, but not only. If you cannot efficiently diff and merge a format having the file in git gains you as little as having a binary file in git. From a practical standpoint, text format is necessary but not sufficient for being usefully trackable in git. You should be able to export it as a musicxml and import that to MU 3 with little loss of content or formatting.This is good to know and technically correct. Having given those warnings, all is not lost if all you have is a MU4 version of a score. There is no guarantee that scores produced now in the latest version of MU 4 will be compatible with later development versions. It should not be used for "real" work, or at least if it is used it is at your risk. Version 4 is still undergoing development and the available versions are intended to be used only for testing purposes to uncover the remaining bugs. Version 4 files indeed cannot be opened in version 3. If that doesn't work you should report the problem on Github as described in the MU4 beta release announcement. See Īssuming your Muse sounds have been updated you also need to update to the latest nightly version of MU4. There has been an update to Muse Sounds that prevents older (i.e.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |