Re: Measure-free scores

Glen has raised an interesting alternative: allowing barlines to be
notated, rather than thinking of measures as containers.

In fact, that is exactly the solution I use in my software LenMus/Lomse. It
allows a uniform treatment of single metric scores, measure-free scores
and, not yet mentioned, *multi-metric music*. But I'm not defending this
solution. I would like just to raise the need for careful thinking about
the a clean MNX solution not relaying on 'tricks' such as:

- non-controlling barlines for CWMN multi-metrics music.
- hidden measures / barlines for CWNM measure-free music.

Multi-metric music is also related to the issue of notating barlines at
<system> level or at <part> level, raised in another post.

In my experience it is, perhaps, simpler to deal with a solution based on
measure containers (with an special measure container for measure-free
scores). But to deal with multi-metrics and measure-free scores I have
cosen a solution based on notating barlines as staff objects and not using
measure containers gives more flexibility and is, IMO, more 'natural'.
Anyway, I'm not defending this solution. I just tried to take into
consideration the need for a clean solution in MNX for multi-metric and
measure-free scores.

Cecilio

On Sun, Apr 2, 2017 at 1:31 PM, James Ingram <j.ingram@netcologne.de> wrote:

> 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
>