Re: Measure-free scores

Hi Glenn,

This discussion of application internals may look a bit private, but I 
think this CG needs need to explore the needs of /all/ its app 
developers, not just the big commercial ones.
I'm currently leaning towards the inclusion of <measure> in MNX (see below).

Glenn said:
> [...] if [...] no or few known program's internals use measure as a 
> container, why should MNX? It would only add complication to programs 
> that don't.
I don't think the complication would actually be very great. Its just a 
case of having another level of looping in the parsing function. On the 
other hand, including <measure> might considerably simplify the parsing 
for some applications. Imagine trying to parse my measure-free SVG 
format to create a list of <measure> objects! I think we'll just have to 
wait and see how the commercial vendors want to do this.

Glenn again:
> My internal data structure is time based, rather than graphics 
> based... all items across a system are grouped if they "sound" 
> concurrently (of course, rests don't exactly sound). I call these 
> items "syllables", derived from the "hunk of lyrics" that is 
> associated with some of them [...].
I'm not sure that I understand you correctly. Is the following correct?:
1. The top level of your internal data structure is a list of *system* 
objects.
2. Each *system* contains a list of *syllable* objects.
3. Each *syllable*
     a) occurs at a particular time and
     b) contains a list of concurrent *item*s.
Presumably, the *syllable* happens at a time relative to the *system*, 
and the *system* happens at a time relative to the performance. The 
duration of a *system* is the duration of its list of *syllable* 
objects. So each *syllable* has a duration (including the last one on 
the list).
At this point, your *syllable* is sounding rather like what I call a 
*<score:midi>* object in
https://github.com/notator/Moritz/issues/3

But then you say that a *syllable* can contain a "hunk of lyrics". Is 
that a recording (something temporal), or do you mean a string of text?
If you mean a string of text, then I think your *syllable* has to be 
extended to contain a graphics component. In other words, it becomes 
equivalent to an MNX <event> symbol (if such <event>s contain both 
graphics and temporal info).

Is that correct? Did I get something wrong? If I'm right, then you 
should have no trouble reading MNX <event> symbols into your internal 
data structure.

> Note that performance directives that change the sequence of play 
> (repeats, D.S., D.C., Coda, etc.) prevent the sequence from being 100% 
> temporally ordered.
The arrow of time is notoriously inexorable! :-)
Apropos repeats, D.S., D.C Coda etc.: In my proposal, <event> symbols 
have a duration that is independent of their absolute temporal position. 
Global time is just the result of adding such durations. If <event>s are 
repeated later in a performance, their durations just get added again.
Since I'm allowing particular <event> symbols to contain multiple 
temporal interpretations, its quite conceivable that a repeat of the 
graphics would use a different interpretation. Real performers never 
play the same thing twice...

All the best,
James



Am 03.04.2017 um 04:27 schrieb Glenn Linderman:
> Given James' and Cecelio's discussion of internals, I'll go ahead and 
> roughly describe my internals. Of course, it is not necessary that the 
> XML map directly to anyone's internals, it is expected that everyone's 
> internals will be different, for different goals and purposes. On the 
> other hand, if there be no or few known program's internals use 
> measure as a container, why should MNX? It would only add complication 
> to programs that don't.
>
> As you might expect from my lead-in paragraph, my program (not public, 
> but has been used to create over 30 books of music and lyrics) does 
> not use measure as a container.
>
> Neither does it use any graphical structure as containers, such as 
> James describes regarding pages, systems, lines, and movements. 
> Rather, pages and lines are scattered about where needed in the 
> temporal order, in a manner similar to, and sometimes independent of, 
> the locations of barlines (as James describes, sometimes it might be 
> that a measure cannot fit on a line, but more often the case is that 
> in fitting music to book form, that certain measures are broken to 
> assist in the layout).
>
> My internal data structure is time based, rather than graphics 
> based... all items across a system are grouped if they "sound" 
> concurrently (of course, rests don't exactly sound). I call these 
> items "syllables", derived from the "hunk of lyrics" that is 
> associated with some of them, but it probably isn't the best name... I 
> just never took time to discover or create a better term (suggestion 
> welcome).
>
> Into this temporally linear data structure of notes, rests, barlines, 
> and performance directives, then, additional "syllables" are inserted 
> for layout purposes (which I call layout syllables), and they contain 
> sufficient information regarding the page layout, the need for clefs 
> and signatures, system connectors, and margins in both dimensions.  
> There is generally at least one layout syllable per line of graphical 
> music.
>
> I don't claim this is the best structure for all purposes, but it has 
> been generally satisfactory for my use for the last 34 years. 
> Initially a binary structure, I have converted it to compressed JSON 
> in more recent times, finding paired XML keywords generally more 
> distracting than helpful, but as an interchange format XML probably 
> has more mature tools for schema description and validation (although 
> such tools could be written for JSON, and maybe have been, unknown to 
> me).
>
> Note that performance directives that change the sequence of play 
> (repeats, D.S., D.C., Coda, etc.) prevent the sequence from being 100% 
> temporally ordered. Playback simply follows the directives, 
> accumulating key points (begin movement, begin repeat, Segno, Coda) 
> which may be return points as they are discovered, and treating the 
> others (end repeats, D.S., etc.) as a go to... just like a human 
> player would, given the printed notation.
>
>
>
> On 4/2/2017 10:29 AM, James Ingram wrote:
>> I'd like to add a couple of points:
>>
>> 1.  My measure-free solution for SVG instantiations is not an argument
>> for leaving measures out of MNX.
>> My authoring software (which would be an MNX /client/) uses measures
>> internally, so that its easy to concatenate them for particular system
>> layouts. It might be better to make it easy for such apps to construct
>> an internal structure consisting of a flat list of measures, so that
>> they can then give their users the choice of where the system breaks
>> should go. Such a container hierarchy might be:
>> page-->system-->measure-->staff-->voice-->event.
>> (I still think that MNX containers should be /graphically consistent/
>> containers.)
>> It would be possible, using this hierarchy, to write a valid MNX file
>> containing a single measure that would not fit on any available page.
>> (MNX has no idea how big the page is going to be.) In such a case, the
>> MNX client app has to be able to break the measure anywhere its user
>> thinks would be a good idea. That's just a problem for the app, its not
>> the MNX format's problem. The app can then export SVG (maybe in a format
>> like the one I outlined) or a new MNX file. The MNX for this "one
>> measure score" would have one measure per system, and all the final
>> barlines except the last would be missing (or invisible...).
>>
>> 2. Note that this is all has /only/ to do with the graphics. (The way
>> the score /looks/.) Any temporal information contained by an event
>> symbol just moves with its container, and can be concatenated across a
>> particular voice to describe a continuous stream. On the graphic level,
>> annotations such as time-signatures, tempo markings, tuplet brackets,
>> augmentation dots, staccato dots etc can be added ad lib., but a
>> complete description of what they all /mean/ will still just be stored
>> in the event symbols.
>>
>> 3. Please excuse my frequent use of "bar" to mean "measure". I actually
>> prefer the UK-English terms, since bars are just objects in space (that
>> are aids to legibility). Nothing is actually being "measured". Similarly
>> for the duration class names:  a crotchet was originally a hook-shaped
>> object -- its not a quarter of anything...  :-)
>>
>> All the best,
>> James
>>
>>
>> Am 02.04.2017 um 16:04 schrieb cecilio:
>>> 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
>>> <mailto: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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>