RE: Measure-free scores

James, 

 

You start wrong by imposing pages as the top-level entity. That’s wrong. 

The main error is that you assume a fixed width, and hardcode that in the exported MNX file. That’s fundamentally wrong for a number of applications. 

 

Coming from the tablet side of things, I can assure you that the first thing people do when they grab one of our tablets is to rotate them, and see what happens. Most of them expect the music to automatically reflow to fit the width of the screen. And while screens indeed have a fixed width or height, there are screens that people use that have different width and heights. 

 

But there are other reasons that this is wrong. A lot of the “new” viewers allow musicians to create their own “custom” sheet music. Including staffs/systems of other instruments, for example. Defining the cue notes you want to see. Indicating where you (as  musician) want the staff break to happen, etc. As a musician, I often want to break free from the engraving decisions made by the publisher/editor/engraver. Hardcoding those in MNX makes that next to impossible. 

 

As I always say to publishers that insist we display the music as they engraved it: “Perfect. Let’s use your PDF file for that purpose”. If the layout/graphics needs to be completely fixed (which seems to be your position), then there really is no need for a standard like MNX. 

 

As you write, your proposal originates from seeing a score as a “graphical environment”. The core usage of MNX is however to move away from this graphical environment and allowing the end-user devices to make the engraving/annotation/… decisions. 

 

Regards, 

 

JanR

 

 

 

 

 

 

 

 

From: James Ingram [mailto:j.ingram@netcologne.de] 
Sent: zondag 2 april 2017 13:32
To: Glenn Linderman <v+smufl@g.nevcal.com>; Dennis Bathory-Kitsz <bathory@maltedmedia.com>; public-music-notation-contrib@w3.org
Subject: Re: Measure-free scores

 

Hi Dennis, Glenn, all,

Welcome Dennis! This is getting very interesting! :-)

My own version of the container hierarchy was created from first principles, and does exactly as Glenn suggests: It treats barlines simply as notated lines. They are graphical aids to legibility rather than being musically structural. They just chunk areas of the page to make reading easier.

For discussion purposes, here's my reasoning:

My outermost container is the *page* (an <svg> element in an SVG document). Printable pages have finite width and height. So do computer screens. It is possible to scroll pages on a screen, either horizontally or vertically, but scrolling very wide pages horizontally is strangely disorienting. System breaks are reassuring, and aid to legibility. So my *page* containers always have a width that should fit on a computer screen. The authoring software can decide which screen width the score is written for.

(From here on, I'm simplifying a bit, for the sake of getting the principles across.)

The next container level down (inside *page*) is the *system*. Systems stack vertically on the page with margins to the left and right. System containers contain *staff* containers and *staffConnector*s.

A *staff* has the width of the system. A *staffConnector* is a vertical line between two staff containers. Staff containers stack vertically inside their system, and contain *voice* containers. 

A *voice* container has the width of its containing staff, and contains a sequence of objects that include *clefs*, *barlines* and *event symbols*. (This arrangement owes a lot to capella's CapXML "noteObject"s. )
My authoring software only draws *barline*s into the first voice in a staff. It might be better to draw barlines a level higher, in the staff container.
An advantage of differentiating between barlines and staffConnectors is that they can be styled differently. Stockhausen often wanted to group instrument types differently in this way. For example: In a large score, the staffConnectors between woodwind staves can be the same thickness as the barlines, while the staffConnectors between the woodwinds and the brass can be thinner.

XML was invented to be both machine-readable and human-readable. Its a big help, when debugging, to be able to collapse the containers in an XML editor in order to find a particular object. So I think its a good idea to make the XML containers contain everything that belongs graphically inside them. I'd therefore prefer it if <part> elements in MNX §5.1.2 were contained in the <system> element. (If I've understood the example correctly.)

Note that my version of the container hierarchy is based strictly on graphical containment. The old problem of moving notes from bar to bar is still there, but it has become a problem of moving notes from system to system.
Note also that the temporal definition of a tied symbol goes in the first event symbol. All the rest (tie, tied symbols) is just graphics.

All the best, hope that helps,
James



Am 02.04.2017 um 01:20 schrieb Glenn Linderman:

Dennis raises a valid point, though... does a measure have to be a container at all?  A measure extends from one bar to the next, but the sequence of notes and bar lines can be thought of as a exactly that, a sequence, rather than a containment concept.  As has already been mentioned, sounded notes can escape the containment by being tied across bar lines. Further, shifting things from one measure to the next may be far easier by moving the bar lines in the sequence rather than moving notes from one container to another. So there are some merit to simply allowing bar lines to be notated, rather than thinking of measures as containers (either in the logical or XML sense of containment). 

On 4/1/2017 12:05 PM, Joe Berkovitz wrote: 



Hi Dennis, 

    Speaking as a composer, "one big measure" is still some sort of 
    container and 
    therefore incorrect. I have not understood in these discussions and in 
    existing software why the measure must be the  basic consideration 
    in encoding 
    information. 


If we used a <measure> element in this way, it would be just a 
"container of convenience" to hold a series of events and would not 
imply a notated measure. We'd want to figure out a way to make sure that 
this understanding was part of the encoding. I wish I had not used the 
term, "one big measure": I simply meant, one big container. It may make 
sense to name the element differently in this case -- that, too, is up 
for discussion. 

Truly, there's no claim here that measures are a basic consideration in 
encoding music. Where measures exist and the composer notated them, 
though, I think it's reasonable to include them in the encoding as part 
of what the composer chose to express. Where the composer didn't do so, 
then the encoding can say that too. 

With respect to the other generalities that you talked about, I think 
we're envisioning that MNX will *also* include a culturally neutral 
encoding approach based entirely on graphics and time, and that this 
will provide an escape valve for the many notation systems that don't 
fit the 1600-1900 model. The emphasis you see in the CG's work right 
now, in no way excludes our taking up a more general approach as our 
resources and time allow. 

I don't feel there is a "tendency to create a [traditional Western] 
system". It's just that there is a large proportion of CG members 
writing applications that work within this system. Our present 
priorities merely reflect the makeup of the group. And they are just 
priorities, not decisions about what notation is or is not. I look 
forward to having the time to devote to thinking through the more 
general graphical/temporal approach as well. 

Best, 
...Joe 


    Music proceeds. If a measure-based composition is encoded, then 
    apply the 
    markers that determine these aspects (barlines, time signatures, etc.). 
    Dumping the measure, it seems to me, relieves all the struggles with 
    time 
    signatures (such as 4/3 or 3/7) and, of course, notation systems old 
    and new 
    that don't use measure-like divisions at all. If a time-based system is 
    encoded, then the container, if you need one, can be the second. If an 
    instrument-exchange based system is encoded, the container (again, 
    if you need 
    one) is the exchange division. If the answer is 'none of the above', 
    then the 
    encoding system should be required to respect the music -- first. 

    With no measure container, for example, having a continuous staff 
    that changes 
    as needed (containers, no containers, switch to time-based, 
    directional, all 
    on the fly) also frees the encoded notation from straight, 
    horizontal lines 
    (meaning no trouble encoding Wolff or Stockhausen). 

    I'm not a coder anymore, but I see a tendency to create a system that is 
    driven by Western music 1600-1900. Don't we already have plenty of 
    systems 
    that do that? It seems to me that any new system that depends on that is 
    either mostly redundant or, with respect to the continuing 
    development of 
    music, destined to fail. 

    So can the measure 'container' please be scrapped? 

    Dennis 









 

-- 

https://github.com/notator
http://james-ingram-act-two.de