Creating a customised legacy build of 2.0.1 for Win7
I've been holding a set of six motets back from production for 9 months now, hoping a useable version incorporating this patch , would become available, but it hasn't. The PR is still open, and we can all hope the feature will eventually appear in 2.0.4 or later, but there's no telling when that might happen, of course, and this feature is not currently available in any nightly build.
My additional problem is that all six scores were created using 2.0.1 (b25f81d), and for a number of reasons I don't want to revise them using a different version if I can avoid that. The note and lyrics input, proofreading, and page make-up have all been done, and the only thing that needs adjusting is the spacing of the melismatic dashes in the lyrics, which this patch would allow me to do.
Unfortunately, I am not competent to create a custom build using the patch code that Miwarre wrote, and he does not run Win7 so he can't help me, either. Is there anyone out there who does run Win7 who would be willing to help out with this?
Comments
To clear up a possible confusion, this patch will not make it in 2.0.4 or later 2.0.X version. It adds two new style parameters and it's not possible to add style parameters in the 2.0.X line. Any new style would crash an older 2.0.X version and so completely break the compatibility...
In reply to To clear up a possible by [DELETED] 5
I compile my own builds using a custom script, from which I can create local branches and incorporate pull requests for testing. I've done these custom builds-with-pulls for others. However, I don't know the GIT commands to change to a different code branch other than "master". So if someone can show me how to switch in GIT to the 2.01 codebase, I will attempt it. Note I will be compiling with Qt 5.6.0 and not 5.4.x which 2.01 likely used.
In reply to I compile my own builds using by schepers
master is a branch like all others too, so whatever you use to switch to local branches should work for the 2.0.1 branch too. "
git checkout 2.0.1" should do.MuseScore 2.0.1 won't work with Qt-5.6 due to the lack of QWebEngine (or some such), needed for the start Center, but discontinued in 5.6
In reply to master is a branch like all by Jojo-Schmitz
Thanks Jojo. So Qt 5.4.2 should be OK? I still have that around.
In reply to Thanks Jojo. So Qt 5.4.2 by schepers
yes
In reply to Thanks Jojo. So Qt 5.4.2 by schepers
A "git checkout 2.0.1" fails with "2.0.1 did not match any file(s) known to git". 2.0.2 is there. If I select the tag category, 2.0.1 exists but then shows up a 2.0beta1 for branch.
I really don't know what to do. Perhaps I will see if the source tarball is around.
In reply to A "git checkout 2.0.1" fails by schepers
OK, got the 2.01 source tarball, and modded my compile script so it's compiling now. What value needs to be changed?
In reply to OK, got the 2.01 source by schepers
OK, I changed the LYRICS_DASH_DEFAULT_STEP from 16 to 8 and uploaded the customized 2.01 to
http://ist.uwaterloo.ca/~schepers/musescore/MuseScore201-32bit-Qt541.rar
Download and enjoy!
In reply to OK, I changed the by schepers
If that is the only change, it should be fully compatible with any other MuseScore release >= 2.0.0
In reply to If that is the only change, by Jojo-Schmitz
It was his suggestion and seemed the easiest thing to do.
In reply to It was his suggestion and by schepers
indeed, and no compatibility Problem, other than, I guess, that all other versions would still render the mscz using the old value, so one would need to create PFDs with this customized version to see the smaller distance between multiple lyrics dashes in print
In reply to OK, I changed the by schepers
Thanks; I've downloaded the .rar files, but I am not sure how to extract and install them. This computer runs Win7 professsional, 64-bit, version 6.1.7601. (Service Pack 1). The system does not recognise the .rar format, so I have no file associations to deal with it. I can open the list of files using Open Freely, but that's about it so far.
In reply to Thanks; I've downloaded the by Recorder485
Download WinRAR 5.40 beta 4 32-bit from www.rarlabs.com. It will unpack for you.
In reply to Download WinRAR 5.40 beta 4 by schepers
Okay, thanks. I downloaded the 40-day trial version, and it did indeed unpack those files, but--and I REALLY feel like the compleat idiot asking this--I still can't figure out how to install the program. In XP, there was a utility that allowed one to ADD or REMOVE programs; in Win7 the ADD function isn't there at all, and unless a downloaded program automatically starts the Install Wizard, I'm stumped.
I would try to run the application from the command line, but I don't know what file to point to.
Sorry for being so useless.... :(
In reply to Okay, thanks. I downloaded by Recorder485
As Jojo said below, it unpacks to an "installed" state. Go into the folder that WinRAR makes (if it did), then into BIN and double-click Musescore.exe
In reply to OK, got the 2.01 source by schepers
Heh. Just reading the vocabulary ('git checkout' 'branch' 'master' 'tag' 'tarball'....) that you guys are using is enough to make me feel like I'm sitting at the back of the 'smart' class wondering what the heck I'm doing there! ;o)
After looking at my actual needs and evaluating the replies from Marc and Zack and Jojo, I think it's best to give up on merging the patch in a custom build. It's pretty clear that would create full UI control of that parameter, but in so doing it would also create incompatability issues. I hadn't realised quite how complex that was.
So we're now talking about ONLY changing the hard-coded value of the maximum dash space in 2.0.1, a much simpler proposition, I hope. If I have managed to understand anything about that code correctly at all, that value appears to be defined in libmscore/lyrics.h on line 63.
static constexpr qreal LYRICS_DASH_DEFAULT_STEP = 16.0; // the max. distance between dashes
(I made that guess by looking through the patch--I would obviously not have had ANY clue where to look otherwise--and I hope it's the right line. I understand this stuff VERY poorly, but I'm trying to learn from you guys.)
Anyway, if I'm not completely out to lunch, that value of 16.0 needs to be changed to 8.0. As far as I can tell from doing manual dash layouts using spatium units, that should generate the dash spacing I need.
EDIT TO ADD: Apparently our posts 'crossed' in hyperspace. I was working on this reply earlier today but had to go rescue a standed boy and just got around to posting it. When I did, I saw your post with the link. Thanks! I will download that and let you know how it works out!
In reply to Heh. Just reading the by Recorder485
FWIW, your approach to figuring it out is exactly what I would have done as well. I am not particularly familiar with that area of code, so looking at a PR to see what parts of the code it messes with is a great way to start. Of course, I can only guess that 8sp is a good value for you; if the version schepers built for you doesn't quite cut it, you might yet want to build it yourself and play with other values.
In reply to FWIW, your approach to by Marc Sabatella
Thanks, Marc. That's higher praise than I feel I deserve. It only seemed logical that Maurizio would have removed the hard-coded parameter to allow a user-configurable control field to replace it, and that was the only line of code in the whole patch which did that. (It also helps that he and I had discussed the fact the current setting was 16.0sp, so I just looked at every line of code with that number in it anywhere. Not exactly rocket science, as they say....)
But this has been my day for feeling technology-challenged: Now that I've got the modified program, thanks to schepers, I can't figure out how to install or run it (DUHH!!!), and on top of that my brand-new Blackberry Classic just arrived by Purolator and the sim card is the wrong size and I can't even get the darned thing hooked up to my wifi network. The prospect of sanding a few thousandths of an inch off a swollen jack in my harpsichord (to compensate for the current high humidity) seems very comforting by comparison. I am sooooooo old-school.... ;o)
In reply to Thanks, Marc. That's higher by Recorder485
I think ((edit: now I'm sure) you don't need to install it at all, just unpack and execute (read: double-click) the musescore.exe (edit: win32install/bin/MuseScore.exe, similar to a nightly build or the portable app, same as a self built Version, which is what it is
In reply to I think ((edit: now I'm sure) by Jojo-Schmitz
Heiß verdammt! It works!!
Original 2.0.1 rendering:
Modified 2.0.1 rendering:
Awesome!
In reply to A "git checkout 2.0.1" fails by schepers
You're right, sorry, there is no 2.0.1 branch, just a tag
In reply to I compile my own builds using by schepers
@schepers--That is very generous of you to offer to help out on this, but as you can see from Zack's reply, it doesn't seem like the result would be stable enough to use in any practical sense.
However, another possibility occurs to me: It is not absolutely essential that I have full UI control of the max dash spacing parameter, as long as I could change the current parameter of 16sp to a smaller figure. (I have a pretty good idea of what setting I need for all my vocal scores.) Maurizio--the man who wrote this patch--told me that the max dash spacing was 'hard coded', but I am not sure what that means. Does it mean that the hard-coded parameter is in one of the registry keys, and could thus theoretically be edited there using RegEdit? I would be willing to do that myself if someone could guide me through the process of finding the right line of code. I have done that before in a few other cases where a single change was necessary to get things running the way I wanted them.
In reply to @schepers--That is very by Recorder485
There's no reason it shouldn't be stable—it's just that scores saved with it wouldn't be openable with your regular, un-customized 2.0.1.
In reply to There's no reason it by Isaac Weiss
Hmmm. Okay, but would the inverse be true? IOW, would scores created using the standard version of 2.0.1 refuse to open in the customised version? (Or would they likely be corrupted if they did?)
In reply to Hmmm. Okay, but would the by Recorder485
Unlikely—the customized version would have everything 2.0.1 had. But they would be "corrupted" in the sense that the files would afterward no longer be compatible with any released 2.0 version.
In reply to Hmmm. Okay, but would the by Recorder485
A score is basically a text file written in a language that is roughly similar to HTML. The change adds a new construct to that language so that if your score uses this new feature, your score will contain that construct (something like "dashspace = 42", although I'm sure that's not the actual syntax). Versions of MuseScore that lack the change - and that includes all existing versions obvious - will see that construct in a score file and say "I have no idea what dashspace = 42" means, and choke. But the special version of MuseScore will have no trouble reading scores created with the regular version - they simply won't contain that special construct.
In reply to A score is basically a text by Marc Sabatella
Marc, your patience with me will earn you a halo in heaven some day, I am sure. And you've inadvertantly suggested yet another approach I hadn't yet considered, so let me ask you one more question: Would it be practical to take the existing 2.0.1 files and export them to xml and then edit that parameter to the new value in a text editor? IOW, would I find that max dash space parameter for every dash series in the whole score, or would it show up only at the head of the score, needing only to be modified one time to affect the entire thing?
But, hmmm....now I'm remembering how many other things get scrambled in the conversion to xml anyway; maybe that's not such a good idea....
In reply to Marc, your patience with me by Recorder485
The whole problem is that there is no language construct for this in 2.0.1 - the value is hard coded into the program itself. So there is nothing in the file to edit. You'd need a customized build with that fix included to even have the ability to use that construct.
BTW, the XML used internally within MuseScore is not MusicXML. I am referring to MuseScore's native language here - nothing is scrambled. It's the only way MuseScore ever reads and writes scores. MSCX is that format; MSCZ is just that compressed into a ZIP file. MusicXML is a totally *different* language that we have to translate to and from when you open or expoert a file in that format, and indeed, much is lost in the translation.
In reply to A score is basically a text by Marc Sabatella
The problem is MuseScore 2.0.0 and, IIRC, 2.0.1, they will just crash when detecting an unknown construct, only 2.0.3 and I believe also 2.0.2 are tolerating and ignoring them.
This is 'intolerance' is the real reason not to include that PR in 2.0.4.
In reply to @schepers--That is very by Recorder485
No, it's not a registry key - it's in the application itself. You'd need a specially-compiled version with that value changed to something else.
In reply to No, it's not a registry key - by Marc Sabatella
Darn. And I can't get to the Application Data folder because this !#$%$!^$$%#* computer won't let me in, even though I log in as Administrator and gave myself permissions for it. Apparently HP has things in there they don't want anyone to see.... :o(
Okay, new question: If a stable version of 2.0.1 were modified to change only that value and then recompiled, would it remain stable? I'm looking at changing that 16sp to either 12sp or 8sp. (I would do some graphic trials first to determine which value I need.)
In reply to Darn. And I can't get to the by Recorder485
I'm not sure what Application Data has to do with anything. I can't imagine there is anything there that would be relevant or useful. Am I missing something?
My *guess* is that if someone were to recompile 2.0.1 with only that change, all would be well. Your scores would still open on other systems; they just wouldn't look the same (they'd look "normal" - same way they look for you now). it's remotely possible something would go wrong as a result, but just like it's remotely possible earth will be struck by an asteroid tomorrow...
In reply to I'm not sure what Application by Marc Sabatella
You're not likely missing anything; I just assumed (probably idiotically) that the actual code for the application would be in that folder, since I can't find musescore.exe anywhere else. Not that I've ever been able to read an .exe file on this machine, anyway; they all open as pure gibberish. I gather that's because I don't have the right software to open them, and Notepad doesn't recognise the characters properly.
So, back to cases. It sounds as if the most practical and safest solution would be to try to get a recompiled version of 2.0.1 with a simple change to the max dash space parameter.
In reply to You're not likely missing by Recorder485
The application is the EXE file in Program Files, but you can't simply edit it - you need to recompile it from source. Well, a sufficiently skilled hacker might be able to figure out how to edit the EXE file directly, but it's definitely not a normal thing to do. It's more along the lines of the skills involved in creating viruses. An EXE file is not meant to be editable or to contain information that would allow anyone to understand its contents in any reasonable way.
In reply to To clear up a possible by [DELETED] 5
@Nicolas--Thanks, and sorry if I'm asking (yet another!) dumb question, but as you know, I get easily confused on stuff like this, and I'd hate to ask someone to do something that won't work anyway. ;o)
If I understand this correctly, this patch will work in 2.0.1, but only in 2.0.1 (and that's why it wasn't merged). Is that correct?
In reply to @Nicolas--Thanks, and sorry by Recorder485
No—rather, scores created in any version of MuseScore that this feature was added to would cause 2.0, 2.0.1, 2.0.2, 2.0.3, or a future 2.0.4 to crash.
In reply to No—rather, scores created in by Isaac Weiss
Thanks for the clarification. I was afraid that it might be something like that.
Well, on to 'Plan B' (see my reply to schepers above)....
In reply to Thanks for the clarification. by Recorder485
I can't tell from the replies... do you want to forego trying this? It would take me a while to get it done, but might be worth it. That's assuming the patch is still compatible with the codebase in 2.01. I'm not up to fixing merge issues.
In reply to I can't tell from the by schepers
Well, at this point I'm still waiting for advice from Marc and Zack. It might be easier and safer just to modify that one parameter in the same stable version of 2.0.1 that I currently have installed. Apparently I can't do that directly in the computer; unless I misunderstood something, the program would have to be recompiled with that modification and then installed as a new version.
In reply to No—rather, scores created in by Isaac Weiss
Well, 2.0.0 and 2.0.1 would crash, 2.0.3, and I believe 2.0.2 won't either, they would just ignore that new feature. 2.0.4 could be taught to not ignore it, but the potential crashes in 2.0.0 and 2.0.1 are preventing us from making that happen