Units of measurement

I was just wondering if there will be an option to specify the types of measurement unit used in a project. From the de facto spaces to points, inches and millimetres or if it would be introducing a proprietory unit such as the EVPU of Finale. If points are employed, would there be an option to choose between post script points and traditional points?

Often the kind of accuracy I look for is 100th of a space but this is largely a guessing game with some of the rounding on space units in a program like Sibelius. Finale also approximates but this isn’t a critique of those venerable applications. It’s just that if I ask for 1.25 sp I would like to get that, not 1.3. Complex scores sometimes call for an exquisite level of control over the elements and if Dorico can demonstrate that, I believe it will open the door to a level of typographic precision matched only by applications such as InDesign or Corel. Different operating systems will also want to perform their own rounding of pixels on the screen and it’s a frequent source of frustration that what we see on screen is often a little “jittery” compared to the printed output. Good basic raw data is essential though and allows us to see past the quantified screen image.

Of course, in print, such fine tolerances are difficult if not impossible to see with the naked eye and most domestic printers will tend to obscure any inequalites depending on factors such as how high or low their native resolution might be. But when we get into small print runs on high quality commercial digital presses on good quality stock these disparities become more obvious. Even offset printing has reached a level of definition that matches or even exceeds the best quality digital prints. My point being that printing technology has moved apace since the inception of applications like Finale and Sibelius and seems likely to evolve in the future.

In the way it handles the precise manipulation of objects on the page Dorico promises to be the engraving platform for the future. But is it future proof?

I’m not the most qualified to respond to this, as a lot of this is outside my day-to-day, but the units of measurement depend on context. For intra-stave quantities that also have to take into account the current stave size, we have a ‘Stave Unit’ type that is multiples of a space. This is a rational type, ie a fraction, so it can deal naturally with quantities like 1/4, 2/3, 143/1000, etc without loss of precision. For quantities that are inter-stave or related to page layout we use a unit that internally we call ‘Puns’ which is equivalent to 1pt. This is a floating point value (64-bit currently), so it should have as great precision as you’re likely to need.

In terms of the UI, I’m not sure what our current plan is as to how to present Pun quantities, but I expect that at some point we’ll allow the choice of points, cm or inches, as those can be converted to an from Puns unambiguously.

Thanks Paul. In terms of the day to day, the context of stave size often calls for fractions of a space and I am assuming the floating point overhead (provision) you describe will allow for a level of precision beyond what we might ordinarily call usefull. It would be cool if we could specify a number like 1/3 though, not 0.333333333333333314829616256247390992939472198486328125!

That sounds like a good idea. I don’t really have a problem with the fact that another notation program seems to use internal units of 1/32 of a space (especially if it comes with a font that was designed to work well on a “grid” of 1/32 units), but making the interface show only 2 decimal places and rounding up and down inconsistently was just dumb. For example are you supposed to enter 1/8 as 0.12 or 0.13? And whatever the “correct” answer to that question is, why do -0.12 and -0.13 work differently?

But for page layout, don’t lose sight of the reality that paper is not a dimensionally stable material, and in any case 4 decimal places of a mm (or a point) is about the same as the wavelength of visible light, so greater precision than that is of no practical significance.

All of the rational units used in Dorico are expressed as rational units in the user interface, not as floating point values (though in a few places you can enter a decimal value and the program will automatically convert into the appropriate rational value, provided it converts precisely into a rational, which of course is not always possible with arbitrary floating point numbers).

Greater accuracy in placement, spacing, sizing etc and less abrupt rounding is of interest to me as well. I enter numeric values quite a bit throughout both Finale and Sibelius currently.

One of the largely unknown features of Finale which I really like is the ability to enter measurements in different units on the fly by using a letter code at the end of the numeric entry in any entry field throughout the application.

So, for instance, if you are viewing in inches but want to enter a value in spaces, you can type “1.25s” and the program understands that as 1.25 spaces. or if you want 1.25 points, enter “1.25p” or “1.25i” for inches. I also employ Finale’s EVPU measurement because it offers a way to enter whole numbers which are easy to remember for very small measurements; “3e” (for EVPUS).

Something like that would be very useful, if not completely proprietary. (Note that because this feature was understood by so few, MakeMusic went on to add drop down menus to change unit of measurement in some, but not all individual dialogs.) But for someone familiar with the shortcut, it is very powerful.

The “Staff Unit” type mentioned by you, Paul, sounds very useful.

I can see how the ability to enter physical dimensions with a “cm” or “in” suffix would be very useful - Photoshop supports this. That probably would be quite simple to do with our model.

It would be amazing, Paul, if those suffixes could be incorporated.

It probably won’t make it into the first version, I’m afraid, but we’ll certainly consider it for the future.

I found it a bit odd that software written in Europe would use fractions rather than decimal points, but I figured there was a good reason. Am I to understand that it is to allow precision when expressing irrational numbers?

I’m not a professional engraver, so perhaps I don’t see the true value of this level of precision. When I’m adjusting a lyric to the left or right by small increments, it gets complex when I need to use 32nds: 1/4, 5/32, 3/16, 7/32, 3/8, etc… In these types of situations, I could do with a bit less precision and a bit more simplicity.

For what it’s worth, we’ve recently done some work to allow the various spin boxes in the Layout Options dialog and the Properties panel that use points as their units to allow you to input any of our supported unit types (centimetres, millimetres, and inches, as well as points). This makes it easier to handle the measurements in the software, especially on the Page Setup page of Layout Options. This won’t be in the forthcoming minor update but will be coming in the next larger one.

To answer your question about the use of fractions, yes, Dorico uses rational numbers to allow for a greater degree of precision. When you move a lyric with Alt+left/right, it moves in 1/8 space increments; hold Ctrl or Command to move them by 1 space increments.

Thanks Daniel for those precise informations, and I am looking forward to these updates that look soooo promising…

“Irrational” is the wrong word (unless you want to make mathematicians cringe!) but the idea is right. You can’t express a fraction like 1/3 exactly as a decimal, and the fact that computers represent numbers in binary rather than decimal doesn’t change that fact. Indeed it makes it worse, because you can’t express most “exact decimal” values (for example 0.3) exactly as “binary decimals” either.

On the other hand you can express any fraction exactly, simply by storing the numerator and denominator separately, and a computer can do exact arithmetic on fractions the same way that you learned to do it in school.

One good reason for this is handling tuplets - if you really want to write a 19/37 tuplet nested inside a 43/13 tuplet, Dorico shouldn’t ever get the arithmetic in a twist because of rounding errors, it just works out the fractions exactly. Of course the position of the symbols on the printed page will end up being approximate (because PDFs etc normally use decimals rather than fractions to position things) but there is no particular reason why those approximations should be worse than one part in a million, which is better than most people’s eyesight!

Footnote: mathematicians call fractions rational numbers, not irrational. Irrational numbers are things like “pi” and “the square root of 2”, and there is no way to write down their “exact” value. Of course you can write down an approximate value that is as accurate as you like (pi has been calculated to 22 quadrillion decimal places, just to prove that it’s possible to do it!) but the sequence of decimal digits never repeats itself - if it did repeat, the number could be written exactly as a fraction and would not be irrational.