72DPI = fixed, but MM = default unit, and further scaling/spatium issues
I am currently focused on generating web-based scores using SVG. My default units are pixels, not millimeters or inches. MuseScore has just recently set 72dpi as a constant scaling factor, yet the default unit of measurement continues to be millimeters. This is particularly ugly for me because of the resulting convoluted conversion formulas, combined with these lines of code in mscore/pagesettings.cpp/PageSettings::updateValues():
if (mm) {
suffix = "mm";
singleStepSize = 1.0;
singleStepScale = 0.2;
}
...
spatiumEntry->setSuffix(suffix);
spatiumEntry->setSingleStep(singleStepScale);
So the default value for a score's spatium = 5 (1/0.2), and now I'm stuck doing this math:
@ 72 pixels per inch
= 2.8346456693 = DPMM = pixels per millimeter, rounded to 10 digits
= 0.5669291339 = 0.2 * DPMM = my "px" (pixels) singleStepScale value, rounded to 10 digits.
This is nuts. The core units are pixels (dots), which are translated by default into inches, which are then translated into millimeters by MuseScore to use as it's default unit of measurement. It's nuts because I'm simply trying to use pixels, which should need absolutely no conversion at all, and I'm now stuck completing the loop by converting from millimeters back to pixels!
It seems to me that MuseScore should move to pixels as its base unit of measurement and convert to millimeters or inches as necessary. I am currently moving in this direction in my branch of code by adding a "pixels" radio button to the pagesettings.ui dialog. I'm not sure what I should do about the default spatium value, as the value of 5 seems arbitrary to me (I'm sure it isn't, but I have no clue why it's set to 5). What do you all think about this? It seems like a good time to discuss it given the recent changes for 72dpi. Also note that this same code in pagesettings.cpp/updateValues() is the source of a couple of rounding errors discussed elsewhere, as it uses hard-coded values to convert inches to millimeters, not the global constants.
edit: So the spatium is the number of lines in the staff? And they're spaced 1mm apart? What exactly is the definition of the word "spatium" in MuseScore, what is its purpose?
Comments
One Spatium is the distance between two lines of a (normal 5 line) staff
In reply to One Spatium is the distance by Jojo-Schmitz
Is that supposed to be the Scaling: Staff Space value in the page settings dialog? In what units, millimeters? And is that why the _spatium variable for each score = 5 (1/0.2), for 5 staff lines? What if my staff has only 3 lines, is it still 5?
This is the crux of my lack of understanding. I can wade through all the conversions, but those two lines of code in pagesettings.cpp set that 5:1 ratio as fixed for all scores. Any form of scaling is registered by modifying that ratio away from 5:1. So if I want to normalize around pixels, which seems to me will reduce a whole lot of complexity from the code, what do I set it to? 1.764? That doesn't seem right. 2? 1? I'm thinking 2 because after the 72dpi change everyone was complaining that scores look smaller than before - many of us were at 96dpi, so it's a 25% reduction in size.
In reply to Is that supposed to be the by sideways
Yes, Spatium is the same as staff space. It is a term in typography, at least in German
In reply to Yes, Spatium is the same as by Jojo-Schmitz
So on the one hand, the page settings dialog version of spatium is:
1 / ((72 / 25.4) * 0.2)
i.e.
1 / (DPMM / 5)
i.e.
5 / DPMM
On the other hand the score's _spatium variable, which is used a lot, is simply 5 (1/0.2). A bit confusing semantically
In the page settings version of the number it's not dividing by 5, so it can't be using the 5 as a sub-division of the staff size as a whole. So what it's doing is fixing the staff spacing at 5 pixels, and the 1.764 is that value in millimeters.
This is starting to make more sense, and line up better with the concept of using pixels as the base unit for storing values internally...
In reply to So on the one hand, the page by sideways
Hmm, I hadn't realized this was a point of misunderstanding or I might have noticed and said something sooner; sorry about that.
A spatium is indeed the distance between staff lines. It is *the* basic unit of measurement in MuseScore, so that things can scale according to that distance. It is why you see "sp" used as the units in almost every window that allows you to set sizes or distances. 1.764mm is indeed the default value for spatium.
That much I am absolutely certain about. The rest, below, is what I *think* is true, but I welcome corrections:
I believe the spatium value is currently stored in neither millimeters nor inches, but rather in "points" - 1/72's of an inch. Although this is relatively new - prior to a few weeks ago, the unit seemed to depend on your system's logical screen resolution (?), so you'd actually see it stored differently on different systems. But there was a big deal recently about a change to standardize on 72 DPI internally, and this work is not quite done (I have an outstanding PR to fix a few remaining issues I've noticed). In any case, in no way shape or form are distances ever stored internally in millimeters or inches - not sure where you got that idea. Those values are used only temporarily in dialogs like the page settings dialog and then converted into either points or spatium units.
Anyhow, the default spatium value of 1.764mm - aka 0.06944" - is, I think, chosen so that a staff five lines (= 4sp) high will be exactly 20 "points" high, where a point = 1/72" (we're talking standard typographical units here). The figure "5" you mention in your reply above is the spatium value in *points* - again, so a standard five-line staff will be 20 points tall.
In reply to Hmm, I hadn't realized this by Marc Sabatella
What you call points = pixels = dots, it's all the same within this context. I've never been concerned with the dictionary definition of spatium, only what it means inside the MuseScore code.
So 20 is a fixed number, as is 5. Why are these not declared as constants anywhere, and used in this code? That should be done as part of the 72dpi changes, shouldn't it?. When my MuseScore was using the Windows default 96dpi, that 5 became 6.667. Now that 72dpi is constant, 5 should be constant too. That would solve another tiny rounding error in the process.
You are confirming my contention that pixels/points/dots should be the base unit of measurement within MuseScore code, regardless of whether it's offered as an option in the page settings dialog. That requires more than just creating and using a constant or two, but I'm starting to code my own version, and we'll see how that turns out. Any advice on that appreciated...
In reply to What you call points = pixels by sideways
Points are *not* the same as pixels. Pixels can be any size whatsoever, and indeed vary considerably from monitor to monitor or printer to printer, and virtually always are very different between monitors and printers. Whereas a point is 1/72", period. So part of the problem is that we *previously* stored spatium and other measurement in "pixel" measurements which were system-dependent. Now they are in points, so always the same on all systems, thus hopefully helping solve some naggings bugs where certain calculations would come out differently on some systems than others.
Anyhow, I agree that 20 makes sense to be defines as a constant to denote the nominal staff size in points. I assume this is also why the music fonts are defined so that 20pt yields the correct sized glyphs, and we scale from there just as we do text. 5 - the spatium size in points - is not really magic a number in itself. It's just the result of dividing 20 - the standard size of a staff - by 4 - the standard number of spaces in a staff. If the world ever changed to use 48 point staves, then we'd still divide that by 4 to yield 12 points for spatium. Or, if the world ever changed to use 9-line staves (which are 8sp tall), then we'd divide 20 by 8 to yield 2.6 as the spatium value. In other word, the spatium value isn't a constant, it's just the result of this calculation, and in any event, the user can override it.
But again, points already *are* the basic unit of measurement almost universally throughout MsueScore code, and I have no idea where you are getting the idea that this is not already the case. So I have no idea what you are trying to change here.
In reply to Points are *not* the same as by Marc Sabatella
I realize that points and pixels are not the same outside of MuseScore code, but MuseScore code treats them identically, and in essence they are the same thing, though that might be too philosophical :-). The SVG exports exemplify the way MuseScore uses a 1:1 translation from points to pixels.
So we are agreeing. I've already changed my page settings dialog's new radio button to read: Points / Pixels, not just pixels.
It is a magic number today, because it is never stated explicitly in the code. It is derived via formula. This is why it is prone to rounding errors.
Points are not the universal reference units in the MuseScore code because millimeters are the default selection and also the default unit of measurement for the variables in the code and at run time. As I said, I'm trying to use points/pixels as the reference point in MuseScore and it is requiring major surgery. Add to that the effort it required to understand all the math going on and back into number 5. I had asked this question previously: "why 5, what does 5 mean?" in another thread and got a solid "i don't know" as a response.
So, again, we are agreeing. It would be in the best interest of the code to revolve around points/pixels, whatever you want to call them, as the core units of measurement.
I'm focusing on 5, not 20, because in practical terms that's the number that's used everywhere. If you have a drumset with a 3 line staff, the total height should be 10, not 20 with wider spacing. It's the number you can change in the page settings dialog, and we don't want to require the user to do the math on total staff size.
Also note: When I say millimeters are the core units, that's all relative to printing/exporting and page attributes. I am not including the entire MuseScore code base - sorry to imply that.
In reply to I realize that points and by sideways
EDIT: wrote the first paragraph before seeing your last sentence, somehow I missed that the first time. So much of it might be irrelevant, still, I'm not entirely clear ]
I still do not understand what you are talking about. Can you show me a specific line of code where you believe measurements to be stored in inches or millimeters? I've worked on this code quite a lot, and over thousanmds upon thousands of lines, I don't recall once ever seeing any value stored in any unit but points or spatium, except the tiny handful of places where the user is asked to specify a value in some other unit. Basically, this dialog and the text style dialog in cases where you deliberately override the default and ask for the offset to be entered in inches or millimeters and that's about it as far as I know. So asdide from those two cases, use of points or spatium is *already* universal, and again, I just don't understand where you are getting the idea that it is otherwise. Maybe if you posted a reference to a apecific line of code via GitHub I could understand better what you are concerned about. But even if there are one or two other places, it's still *practically* universal, so there is no way it is going to be "major surgery" to change everything to points or spatium, because 99.999% of values are *already* stored that way.
And the average user has no idea what a point is. He will *not* want to enter that as the size of a staff space. He knows millimeters and/or inches, so those are the correct values to show in the dialog. I guess you could add points as a third radio button, hbut probably no would would ever select it.
As for drumsets, actually, three-line staves *do* normally have wider spacing, so I'm not quite sure what your point is. The height of a three-line drum staff is 2 (number of staff spaces) times the staff line distance for that particular staff, which is defined to be 2.0sp in the staff properties. So it's 4sp, which happens to work out to 20 points *if* you happened to leave the spatium at the default of 1.764mm / 0.69" / 5 points. But the number 5 *as a constant* has nothing to do with anything here. It is not used in this calculation at all. Only the *variable" spatium, which only happens to be 5 if you leave it at the defaul.
In reply to EDIT: wrote the first by Marc Sabatella
You didn't see my last paragraph because it was an edit too...
I figured that the spacing is designed around the size of the note head font glyphs. And the staves are built around that. Also remember that changing the staff spacing scales the entire score by the new number divided by 5. So 5 is the number of points/dots/pixels that equals zero scaling. To reverse the concept, if you want to scale the score, the way to do it is via this input in the page settings dialog. So 5 is a magic number, a fixed number relative to the MuseScore fonts.
As for example code, look at pagesettings.cpp, where all the page-related values get set. The UpdateValues() function that I quoted, for example.
As for the extra radio button, I'm putting it there because I want to use it. If anyone else wants to publish for the web they will probably want to use it too. It has the added benefit of zero rounding and generally less transforming of the numbers. And how many people change the default staff spacing value? I would never even consider it if I wasn't mucking around in the code.
I wouldn't want a 3-line staff to have wider spacing - the note heads are the same size. What's the logic behind that? And if it now scales the note heads larger (twice the size, really) then it will look goofy as a staff in a larger system with other staves at normal resolution.
In reply to You didn't see my last by sideways
Ah, glad to know I didn't just forget to read the last paragraph :-)
For the record, changing the staff space value is actually a very common operation, people do it all the time to fit more music on the page, create scores that are easier to sight read, etc.
As for why 3-line percussion staves have wider spacing, you'd have to ask the music engravers who over the past decades (centuries?) have decided that should be the case. I guess maybe to keep the overall staff size similar to 5-line staves. The notes are not scaled - spatium is global to the score. Only the line distance is changed, to 2sp for this particular staff. But anyhow, that's how music is traditionally published, so that's how MuseScore does it by default as well. You are welcome to use single spacing in your own scores if you like, via Staff Properties / Line Distance. But I don't think any of this is really relevant.
Anyhow, I am still not sure I understand your point about the numebr 5. Is there some particular place in the code where you see this number being used when it should be a defined constant? We already define and use SPATIUM20 and use that in places where we might otherwise just use 5. Are you saying the definition of SPATIUM20 should be changed, or that there is somewhere we should be using SPATIUM20 but are not, or are you saying something else? I guess I am just understanding where in the code you are thinking there is some sort of problem.
Are these lines setting singleStepSize and singleStepScale what you are concerned about? I think may still be confused. I don't think those lines have anything to do with setting the default value for spatium; they simply control the amount by which the arrow keys increase or decrease the values in the various spin boxes in the dialog.
In reply to Are these lines setting by Marc Sabatella
I thought that might be the case, but my bad assumption helped me understand all the crazy, rounded numbers in mm and inches. So it's the SPATIUM20 that's constant?
One problem is that _spatium (always one fourth of the SPATIUM20) is not just used for staff line spacing, it's also used as a general scaling factor for the score. That secondary usage is, to me, more important than the staff spacing, and it's not in the dictionary definition of "spatium". So regardless of whether a 3-line staff is still 20 points tall, the _spatium value used for scaling is still 5. So 5 is a magic number: the default, un-scaled value for everything, not just staff spacing.
Another problem is that a month ago I uncovered rounding errors in the _spatium value that happen inside the page settings dialog. One of them is mm to inches, which would coincide with this type of integer truncation. The other is rounding specifically caused by the Staff Spacing input box, and the fact that it rounds to 3 digits.
Another problem is that I'm trying to figure out how to get everything oriented around pixels/points so I can have more whole numbers in my SVG, and truly control my page width/height in pixels. I realize people still think in terms of paper, and still print, but paper is fading out in the face of glowing screens and HTML, which uses pixels as its default unit of measurement. Even the notion of pages is essentially obsolete on the web. I'm using 1 continuous page for all my web-base scores.
The page settings dialog is the place where all the page attributes are set, and they are all set in mm or inches. I simply want to avoid the conversion and stick with points/pixels, and it's not turning out to be straightforward. Oh yea, and solve those pesky rounding problems too.
In reply to I thought that might be the by sideways
Well, SPATIUM20 is "constant" as long as we continue to use 72 as the global DPI value and record the spatium in points rather than some other value, yes.
However, you still seem to be misunderstanding some things. _spatium - assuming you mean the score vartiable - is *not* always one fortuh of SPATIUM20. In fact, by default it is *equal* to SPATIUM20. But if you change it in this dialog, then it is set to whatever you change it to. It is the value that represents the nominal distance between staff lines *for this score*, so it cannot possibly be a constant - if it were, you couldn't change it.
Anyhow, this miunsderstanding aside, yes, SPATIUM20 is the value that controls scaling for the entire score, not just staff spacing. This is just as I said before, and indeed is the whole point of spatium to provide a unit of measure so that everything can scale consistently. And that is why this value is used, quite consistently, throughout the code. We *don't* use 5 as a magic numebr anywhere that I am aware of. So once again, please, if you have a specific question about the source, include a pointer to the specific line on GitHub so I can tell what you are talking about. Because when I look in the source, I see SPATIUM20 being used correctly. See for example:
https://github.com/musescore/MuseScore/blob/c012358e711c9445f81b55900e1…
Here we are calculating the current scaling so that we can use it when setting the distance between glyphs within a chord symbol, and as you can see, we correctly do this relative to SPATIUM20. And the same for the hunddozens of other uses of this constant. If there is some particular place where you think we are failing to do this, please pint to the specific line so we can discuss it. But as it is, I just don't see the problem yuou seem to think exists. Everything appears exactly as it should be to me.
In reply to Well, SPATIUM20 is "constant" by Marc Sabatella
My confusion and bad form not checking the value of SPATIUM20 during this conversation:
static constexpr qreal SPATIUM20 = 5.0;line 73, mscore.h.
So SPATIUM20 = 5, not 20. My problems are on their way to being solved. There it is, 5 really is a magic number, it's just named "20".
The likely reason for linking staff spacing and score scaling is the relationship between staff spacing and font size, which defaults to 20pt. That way note heads fit in the spaces consistently at every scale. Though it might make sense to separate scaling and spacing...
And there really are rounding errors produced by pagesettings.cpp. Those rounding errors result in incorrect scaling because they are rounding the value of _spatium, a multiplier. The mm/inch issue multiplies and rounds every time you switch between mm and inch.
Now I can use SPATIUM20 as my constant, it already exists. Sorry again for that misunderstanding. There are still issues in the page settings dialog that should be corrected. I need to get deeper into this code to continue this conversation about other possible excess conversions that are happening.
Note that SPATIUM20 appears nowhere in the pagesettings.cpp code. That is probably part of the problem there.
In reply to My confusion and bad form not by sideways
I would assume the term SPATIUM20 is meant to say, "the value of spatium if we assume a full standard staff is 20 points tall". And again, it does happen to work out to 5 *if and only if* we store this value in units of points rather than some other units. We did not use points as the unit for most of MuseScore's existence, so I wouldn't read to much into the fact that this month the value happens to be 5. Last month it was a calculation involving the PPI figure so it differed between systems. Next month it could easily be something else. Just use SPATIUM20 when you need to know the value, and all continues to be well.
And I don't see any particular reason why SPATIUM20 would be relevant in the page settings dialog. This value is used for one main purpose: to perform scaling. But the page settings dialog does not do any scaling. All it does is take the number you enter for staff space and convert it to points in order to store as the score's own spatium value. That happens here:
https://github.com/musescore/MuseScore/blob/c012358e711c9445f81b55900e1…
There is no reason I can see for SPATIUM20 to be involved in this at all - why would think it would need to be? The actual scaling happens as part of layout, or in the spatiumChanged() methods for the staves or other elements in the score. And even then, it's often more relevant to perform calculations based on the *previous* spatium value than the nominal one, which might well never have appleiud to this particular score.
So, if there are rounding issues when changing units, by all means, see about reducing them, although of course they can never be *completely* eliminated in a floating point world. But any such fix should be localized to just a few lines of code in this file, definitely no "major surgery" of any kind.
In reply to I would assume the term by Marc Sabatella
So far SPATIUM20 has not been involved in my pagesettings.cpp changes. But I am working towards using points as the unit of measurement for page settings.
The base units in MuseScore are points, I think we agree on that. And as I just discovered, MuseScore uses inches as the page settings units at run time, but the file stores it using 0.1 points as the units (see page.cpp Page::write()). Using points as the page settings units at run time makes more and more sense the deeper I dig.
And the rounding errors can be eliminated, in a couple of different ways, one of them being more rounding, the other being unrounded floating point values everywhere. Even I'm not concerned with precision past the 10th decimal place ;-)
In reply to So far SPATIUM20 has not been by sideways
Currently, indeed, most units are represented as points - at least that is my understanding of the basic gist of the big 72 DPI change. Please don't rely on that always being the case though. It wasn't last month and may not be next month. So any changes you make, be explicit about either using points, or using the same system used elsewhere in MsueScore whatever that happens to be.
edit: I have attached a draft of the initial scope of changes to accomplish changing the page format units from inches to points.
And here is possibly my main issue (page.h, lines 72 and 85, class PageFormat, size member:
QSizeF _size;
const QSizeF& size() const { return _size; } // size in inch
Millimeters may be the default in the page settings dialog, but it's stored as inches. So says this comment, and so says the code in pagesettings.cpp, where all things "mm" are multiplied by the constant INCH = 25.4.
I'm sure this makes sense in some way historically, but it complicates things, especially when all the values in the dialog are rounded. 72 divides cleanly by 2,3,4,12, etc., so if you're paper size is in inches, and you're using standard paper sizes, there are never fractional points. This all goes against the concept of using "mm" as a default, and leaves fractional millimeters for pages as a likely outcome. But today fractional millimeters are already a likely outcome because it's stored in inches and converted to mm anyway.
So I'm going to take a stab at storing the page sizes in points, and see how it turns out. It will make the page settings units the same as everywhere else, which is a good thing, isn't it? All 6 occurrences of
QPrinter::Inchin 4 files will change toQPrinter::Point. There might well be other repercussions, but I feel better already knowing that another constant I need already exists ;-)In reply to edit: I have attached a draft by sideways
It would be easier to get a handle on your changes if you simply pushed the branch to GitHub and included a link to it.
In reply to It would be easier to get a by Marc Sabatella
I don't have the changes made yet, I started this topic as a means of finding my way around this maze of unit conversions. So far you've been extremely helpful, and I am now staring at what I believe to be the core of my problem. I will create a branch and post to github when I have something that actually works, hopefully soon.
As for relying on points: it would be a shame if MuseScore went and changed that, but based on my recent experience dealing with these numbers in some detail, I think points is the right decision, and it should stay that way. It is the unit of desktop publishing, and this is a desktop publishing app for music. IMO. I think the more the code settles down, including these changes of mine, it will start to look better and better - fewer conversions and less convoluted formulas. I think it's important to see this not just as 72dpi, but as linking points and pixels in a 1:1 relationship, no conversion factors. That's the best part about this setup.
This is only stuff relating to class PageFormat, which seems to have been overlooked as part of the 72dpi changes - I see some literal 25.4 values in there along with all these conversions from mm to inches.
MuseScore treats page width and height differently in a couple of different ways. Here are 2 examples for the 2 different cases, plus 2 related questions:
1) pagesettings.cpp, PageSettings::updateValues(), line 226:
oddPageLeftMargin->setMaximum(widthValue);oddPageRightMargin->setMaximum(widthValue);
evenPageLeftMargin->setMaximum(widthValue);
evenPageRightMargin->setMaximum(widthValue);
Only left and right margins have maximums, not top and bottom. Why?
2) page.cpp, PageFormat::PageFormat(), line 304:
_printableWidth = _size.width() - 20.0 / INCH;There is printableWidth, but no printableHeight calculation or setting. Why? Is this because of odd/even margins only affecting width, not height?
3) MuseScore stores the PageFormat data using 0.5 points as the unit (I misspoke above when I said 0.1 points). These are floating point values, so it's not accomplishing much in the sense of precision. Is this because of a convention in MusicXML? 144PPI?
4) On a related note: PageSettings::applyToScore(), pagesettings.cpp lines 318-340. Why does this function create a new PageFormat object, set the properties in it, then use Score::undoChangePageFormat() to set the values in the score's PageFormat object? Why not simply set the values within the score's PageFormat object and be done with it? Like this:
PageFormat* pf = s->pageFormat();Then all the startCmd() to endCmd() code can go away. The score's spatium can also be set directly by Score::setSpatium() or Score::spatiumChanged().
In reply to MuseScore treats page width by sideways
I don't have good answers for you, here are what I might start by assuming and then testing these hypotheses:
1) I would *guess* that the reason for the handling of maximum value in left/right has something to do with how they are interconnected for double sided scores.
2) Also seems like a good guess.
3) No idea.
4) Normally the reason for the startCmd / endCmd code is to make undo work correctly. Have you tested thoroughly to set that it still does if you make that change? You might also check the history of those lines in GitHub, using the "Blame" facility, to see where any given line came from. Often you'll see a commit with a useful message explaining the purpose, or including an issue number you can look up.
In reply to I don't have good answers for by Marc Sabatella
Yes, two-sided pages seems to be a prime motivator in width vs. height.
3) is an interesting one. A completely unique unit conversion that only happens reading/writing the file from disk. It's also the most difficult to change because of backwards compatibility. I did a web search for " MusicXML dpi" and "144 dpi" and found nothing useful.
4) your explanation makes sense. Everything that needs to be undone passes through that mechanism. Closing the dialog is one of those undoable things.
As of 15 minutes ago this code is starting to make sense. I'm not used to dealing with UI code in C++, and that has been part of my difficulty grasping the page settings flow of numbers/conversions. The way it handles the PageFormat objects is also a bit obtuse in that there is a Score object in the preview pane, and that score's PageFormat object is updated when a value in the UI changes. But then much of the code uses the UI object values, which always need converting, instead of the existing PageFormat properties of the preview. applyToScore() is the best example of this. This is a hypothesis I'm going to test. I'm hoping to remove a bunch of conversions in the process. Thanks.
In reply to Yes, two-sided pages seems to by sideways
This example relates to Marc's example, posted above, of how the spatium is used to layout chord symbols. harmonyedit.cpp, ChordStyleEditor::setChordList(), line 161:
int size = lrint(20.0 * DPI / PPI);PPI = DPI now, so size = 20. Should this be SPATIUM20 * 4? Or should there be a constant for 20 somewhere? I have a phobia about literal values in the code when they relate to constants that already exist :-)
BTW - the code in Marc's example is the exact reason why I would like to create a single font with alphanumeric characters plus the music symbols - no need for any of that kind of spacing code and the potential goofiness it might produce (sometimes the chord symbol spacing is a bit off to my eye, depending on the fonts being used), instead the font spacing would handle it automatically. But I may not get to that change precisely because the code works this way. The current code allows people to choose the alphanumeric font separately from the music font, which is probably the best thing overall for MuseScore, so I'm not suggesting to change it generally. I'm just looking to streamline my own SVG and create the greatest level of consistency possible across my scores.
In reply to This example relates to by sideways
The chord style editor was disabled a few years ago and is no longer used. It is something I hope to update at some point, and yes, will need to be be brought in line with the rest of the code changes that have happened since then.
But in any case, code like this is still absolutely needed. A single font wiuld mean fixed relative sizes and positions for all glyphs. That is precisely the limitation that the existing code overcomes, allowing for many different layouts using a single font. That is, a simple tweak to a configuration file allow one to control the superscripting of the chord symbol alerations, etc. The code style editor wass a way to do this without the need to hand-tweak the configuration file. But a fixed font would be a big step backwards in flexibility.
In reply to The chord style editor was by Marc Sabatella
As I said, I'm not suggesting changing the current code. I'm even backing off that particular change on my own. It was just a BTW, relating to a previous post of mine in this topic.
Thanks for the info on the chord style editor.
FYI - I just ran all the numbers on the most convoluted conversion formulas I have encountered so far. I'm only changing what relates to PageFormat, but these conversions are used throughout the code in this class, and I touched maybe half of it. It's all in exportxml.cpp, class ExportMusicXml. Also note that the flip side of these formulas is in importxmlpass1.cpp and the MusicXMLParserPass1 class, the same formulas in reverse:
line 309, class constructor:
ExportMusicXml(Score* s)
{
_score = s; tick = 0; div = 1; tenths = 40;
millimeters = _score->spatium() * tenths / (10 * DPMM);
}
line 4551:
measureTag += QString(" width=\"%1\"").arg(QString::number(m->bbox().width() / DPMM / millimeters * tenths,'f',2));
line 5040:
double ExportMusicXml::getTenthsFromInches(double inches)
{
return inches * INCH / millimeters * tenths;
}
double ExportMusicXml::getTenthsFromDots(double dots)
{
return dots / DPMM / millimeters * tenths;
}
_spatium is used as part of the formula, and relative to PageFormat it is not applicable. If your spatium is not the default SPATIUM20 value of 5, the PageFormat values produced by this code will be scaled, and there is no scaling of PageFormat attributes. As far as I can tell, this current code produces incorrect results for the PageFormat values.
getTenthsFromInches() multiplies the inches argument by 144. That's easily reached by simply multiplying DPI or PPI by 2. This uses 5 different variables in its formula to get to the number 144, and one of those variables (tenths) is used twice, for a total of 6 factors in the formula.
getTenthsFromDots() multiplies the dots argument by 16.0704 (rounded to 4 digits), a number I do not currently comprehend, but the formula uses 4 variables, 2 of them twice for a total of 6 again.
getTenthsFromInches() goes unused in my new code, because it was only used to convert PageFormat values in inches to PPI *2 - the same conversion factor in PageFormat::write() and read(). So those value are now simply multiplied by 2. But getTenthsFromDots() is called a lot, and I have not changed any of that code. And you can see that the code in line 4551 uses the same formula as getTenthsFromDots(), resulting in the same conversion factor.
Just FYI, just reporting my findings. I'm close to being done with the conversion of PageFormat from inches to points. It's the holiday season, so it's going a bit slowly...
I have posted an initial draft of code here: https://github.com/sidewayss/MuseScore/tree/SMAWS
This code changes the Page Settings base, internal units from inches to points/pixels, and adds a "points/pixels" option in the page settings dialog. For clarity I have rearranged/renamed some of the core constants, for example INCH is now MMPI, millimeters per inch. Being a user of inches, that was messing with my head; but that is obviously not a necessary part of this change, just a personal preference of mine, being a citizen of the land of inches.
In general, the new code has fewer conversions of units, and those conversions that remain are less complex. The import/export XML modules lurk as a potential point for problems. As I posted previously, those conversions were quite complex, and possibly even wrong. As a result, I might be missing something by having simplified so radically.
This SMAWS branch includes all the current code for my animated SVG and VTT export. It compiles and seems to generally work just fine, except that I've broken the text exporting part of my SVG export. It exports every character as &#FEEE, instead of the correct hex value. I have no idea how I might have broken that, but I have another branch where that is working properly and I hope to have it all figured out soon enough.
Also note that I have not updated this with the latest changes from the master. I wanted to post something that at least compiles and generally works so as to regress and fix my text problem and have a baseline backed up. I'm still adapting to the git workflow.
I believe the change is an improvement, once the wrinkles are ironed out. And separating it from the animation-related code is not a big deal. I'm interested to hear what others might think. Thanks.
In reply to I have posted an initial by sideways
Maybe I am missing something, but that link does not appear to show any diffs. I think you may have done something wrong merging. Not sure why you merged anything at all. All you should have done was create the branch, make your changes, commit them, then push, nothing more.
In reply to Maybe I am missing something, by Marc Sabatella
Wow, that's exactly what I thought I had done. But I was wrong. It is now here:
https://github.com/sidewayss/MuseScore/commit/0c1b02595be573eaabc6e20c4…
I have posted a working set of changes to convert PageSettings base units from inches to points/pixels here:
https://github.com/sidewayss/MuseScore/tree/pxSMAWS
Here is the compare page vs. my slightly old master fork. It illustrates only the changes I made, none of the 12 recent MuseScore commits I haven't yet merged:
https://github.com/sidewayss/MuseScore/compare/master...sidewayss:pxSMA…
It includes my animation code, because that's the first place I want use these changes. Page Settings dialog has a 3rd option for points/pixels, etc. My previous problems with bogus character codes turned out to be purely when running the debugger in the Qt Creator. If I deploy and run the win23install/MuseScore.exe everything is just fine.
It does succeed in simplifying formulas and eliminating conversions in various places. The Points/Pixels option is the last (bottom) of the three units options visually, in spite of being the new default internal unit. No presumption of the new option being instantly popular...
Please take a look at it and let me know what you think. I would like to submit a PR for this, as I'll be using it a lot, and it can be made 100% SMAWS-animation-free very easily. SMAWS only affects 3 files in /mscore: file.cpp, svggenerator.cpp, svggenerator.h.
I request a review prior to submitting the PR because, as you can see from the second link above, it includes changes to 28 files. Even subtracting the 3 files with animation changes, that's a sizable number of files. Page Settings are used many more places than SVG Export, my one current contribution.
These links supersede the one in my immediately previous post from Jan 4.
Thanks!
In reply to I have posted a working set by sideways
I'm afriad I see all sorts of places where it seems you have somehow dirtied your branch with code from other unrelated commits. Looks like you've somehow partially reverted some other commitsma dnt he nature of the changes is such that I don't think it will compile as is. Eg, there's no way removing a single closing brace from the end of exampleview.cpp could be a good thing.
In reply to I'm afriad I see all sorts of by Marc Sabatella
OK, this is where I start from scratch with a new fork and start using the command line for git 100%, following the instructions to the letter. I'll edit this post when it's all done. I had tried to manually sync this branch, and it did not work as expected, so it's time to go all in.
Thanks.
EDIT - This is now done. The previous links should work, but here they are again:
https://github.com/sidewayss/MuseScore/tree/pxSMAWS
https://github.com/musescore/MuseScore/compare/master...sidewayss:pxSMA…
Here is an issue with the git workflow instructions:
#5) readme for post checkout hook says to execute this:
$ cp -p build/git/hooks/post-checkout .git/hooks/But -p is not an available option for the cp command. I ended up copying the post-checkout file into the .git/hooks folder manually in the file explorer.
In reply to OK, this is where I start by sideways
the -p is to keep permissions, if your cp doesn't have it, simply drop it.
See http://man7.org/linux/man-pages/man1/cp.1.html:
-p same as --preserve=mode,ownership,timestamps
In reply to the -p is to keep by Jojo-Schmitz
Thanks. (So why didn't a google search for unix cp -p reveal nothing useful? Oh well.)
And of course, I made a mistake with my first 100% command-line commit, and committed an extra, old version of a file: mscore/shortcut.cpp. I used the command line to checkout the origin/master version of the file, then did a second commit. I realize that might not be the best solution, but I'm still learning the command line in detail.