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