Re: Notations in Scope

Hi Joe, all,

Before replying to Joe, I'd first like to first make another iteration 
through defining what a "Performable Notation" is.
I currently have:
> A *Performable Notation *is one in which one or more synchronous 
> events can be mapped to one or more graphic objects in the score.
This needs breaking up into some sub-definitions. I want to use the term 
'object' to mean something that is perceptible and spatially extended, 
and the word 'event' to mean something that is perceptible and 
temporally extended. These two words are heavily used already in 
computing ('object' is a base class in Javascript, 'event' is used 
everywhere to mean an instantaneous trigger), so I need to do the 
standard thing -- define a namespace. I'm going to call it 'score'. I 
can now make some more formal definitions:

  * a *score:object* is perceptible in space. It therefore has non-zero
    width, non-zero height, and a defined position (x, y) on a page in a
    score. *score:object*s can /nest/**.
  * a *score:event* is perceptible in time. It therefore has a duration
    greater than or equal to 1ms and a defined position (msPosition)
    with respect to the beginning of a performance. *score:event*s can
    /nest/.
  * a *score:durationSymbol* is a container that has a duration.
  * a *score:chordSymbol* is a *score:durationSymbol *containing a
    *score:object* and one or more *score:event*s.
  * a *score:restSymbol* is *score:durationSymbol* that contains a
    *score:object* but no *score:event*.**

I can then say:

  * A *Performable Notation* consists of *score:object*s and
    *score:durationSymbol*s

Notes:

  * The same *score:event*s can be associated with different
    *score:object*s -- i.e. different scores of the same piece are possible.
  * The same score can contain multiple audio renderings (Use Case MC10)
  * Nothing has been said about how *score:event*s are allowed to nest.
    In fact they can nest both synchronously and consecutively. A
    performed melody is a *score:event*.
  * a CWMN chord symbol is a *score:chordSymbol*. If it is decorated by
    an ornament sign, then it will contain several consecutive
    *score:events*.
  * some *score:object*s are containers (e.g. system, staff, voice
    etc.), some are just /annotations/ (e.g. slurs, 8va signs,
    performance instructions, hairpins, instrument names that are the
    labels of staves etc.).

Comments and suggestions for improvements would, of course, be welcome.

In my reply to Joe, I'd like to refer to the Architectural Proposal I 
made on 9th April. In case anyone has lost the original posting, I 
include it at the bottom of this posting.

The core proposal is that we should think in the following terms:
> There is an authoring application (AUTHORING_APP), that creates an 
> instance of a score (INSTANCE).
> The INSTANCE is parsed by an application (PARSING_APP) that does 
> something with the contained data.
> The AUTHORING_APP makes a contract (CONTRACT) with the PARSING_APP 
> telling it how the data can be parsed.
In the case of CMN, the AUTHORING_APP//would be one of the applications 
that allow their users to create CMN score INSTANCEs/./ Applications 
that create other kinds of score (e.g. Braille editors, or my Moritz) 
are also in the AUTHORING_APP category.

Joe said:
> [snip] SVG is a nice existing standard covering graphic objects, it is 
> far more open ended than MIDI. MIDI is in my view not much better than 
> CWMN (and is arguably worse) in the range of musical events that it 
> can represent.
To be consistent with the condition that we shouldn't mention specific 
technologies, I haven't actually mentioned SVG or MIDI in the formal 
definitions above. However, I think SVG is going to be important because 
it is closely related to /printing/. Many existing AUTHORING_APPs print, 
so it should be fairly easy for them to create (extended) SVG from their 
existing code.
MIDI is the best (only?) standard for temporal events that we have got. 
I can imagine using mp3 files as little building blocks, but that's far 
less flexible. The PARSING_APP might want to play the score at half 
speed, for example. That's quite trivial in MIDI, but very difficult to 
achieve on the fly with audio files. MIDI is also very flexible and well 
connected in other areas too. The MIDI output from the PARSING_APP can 
be sent not only to a synthesizer, but also to apparatus controlling 
lighting or other things. See Use Case MC13.

The PARSING_APP will often be a web application written in Javascript.
Joe: If you want to use HTML because you have existing libraries that 
you'd like to use, that's fine by me. However, you need an INSTANCE to 
work with. That means you need an AUTHORING_APP to create it. Have you 
got one?

For more about the CONTRACT, see the original posting below. Its very 
much like a schema...

Here's some more about my Moritz and Assistant Performer software:
The INSTANCES, created by Moritz and read by the Assistant Performer, 
use CWN symbols, because they have evolved over centuries to become 
very/legible/ and use space very efficiently. Also, they can be read by 
most musicians. (Note that we do not read consistently from left to 
right, but in /chunks/.)
But I don't use tuplets. Duration classes are defined as bandwidths. For 
example, like this (durations in milliseconds)


I compose with millisecond durations, and let Moritz do the 
transcription. Bars add up at the millisecond level. There is nothing to 
say that all the quavers in the score have the same duration.
Note that Moritz writes scores that contain only a small number of 
annotations. Given an appropriate SVG editor, it would be quite 
straightforward to add more (phrase marks, hairpins etc.) in the 
annotations layer. Unfortunately Inkscape isn't very good, and I haven't 
tried Corel Draw or Illustrator yet... I know that it is possible to 
draw beautiful slurs (pointed lines) using Corel Draw - presumably 
Illustrator can do that too nowadays. :-)

The Assistant Composer's documentation is here
http://james-ingram-act-two.de/moritz3/assistantComposer/assistantComposer.html
Some scores can be viewed and played on-line by the Assistant Performer at
http://james-ingram-act-two.de/open-source/assistantPerformer/assistantPerformer.html

The SVG files can all be downloaded from GitHub at
https://github.com/notator/assistant-performer/tree/master/scores
They can be viewed quite well on GitHub, but they need to load fonts, 
and that doesn't always work there.
Song Six is obsolete on GitHub. It can no longer be played on the 
Assistant Performer, but it can be viewed at
http://james-ingram-act-two.de/compositions/songSix/setting1Score/Song%20Six.html
where you can play an (unsynchronised) mp3 of it.

Joe: if there's anything I failed to cover from your previous post, 
please raise it again. This post is quite long enough already.

all the best,
James

=================================================
Here's my posting from 9th April, in case anyone wants to read it, but 
has lost it.
To be consistent with the above, I've changed the abstract authoring 
application's name from AA to AUTHORING_APP, and the name of the 
abstract parsing application's name from PA to PARSING_APP.

Hi all,

Great to see you all yesterday. Nice to see that you are all real 
people! :-)

I'd also like to thank Joe for his first draft of the Architectural 
Proposals. There are some really important insights there. However, I 
completely agree with Zoltan, that we need to discuss the architecture 
without mentioning specific technologies (SVG, MusicXML, CSS etc.)

I was only able to finish reading Joe's doc just before the meeting, so 
there wasn't really time for it to sink in, or for me to prepare a 
considered reply.

Here's what's going through my mind this morning:

/I have a working prototype that is an instance of such an architecture./
Here's a description, leaving out the specific technologies:

There is an authoring application (AUTHORING_APP), that creates an 
instance of a score (INSTANCE).
The INSTANCE is parsed by an application (PARSING_APP) that does 
something with the contained data.
The AUTHORING_APP makes a contract (CONTRACT) with the PARSING_APP 
telling it how the data can be parsed.

That's all.

Here's how my prototype fits this model (the code is all open-source on 
GitHub - see [1]):
AUTHORING_APP is my Assistant Composer, which is part of Moritz (happens 
to be written in C#, and runs offline inside Visual Studio).
Each INSTANCE that Moritz creates is a score written in standard SVG, 
extended to contain MIDI information.
The Assistant Composer creates its output according to the CONTRACT [2], 
and (in every INSTANCE) includes an xlink: to a file that tells 
/PARSING_APP/'s Developer how the file is organised.
PA is my Assistant Performer web application. There is a stable, working 
version at [3].

The CONTRACT Moritz uses isn't machine readable,  but that doesn't 
really matter because the Assistant Performer doesn't have to parse the 
file. All that is really necessary is that the Assistant Performer's 
/Developer/ can find out how the file is structured, so as to be able to 
program his app correctly.
Unfortunately I don't know how to write a machine readable schema that 
describes extensions to SVG. Maybe someone here does? If it were machine 
readable, then software could be written that could check if the 
INSTANCE really conforms to the CONTRACT.

More about the CONTRACT:
This just contains the formal names of the objects in the file, and how 
they are nested. The names are supposed to be self-explanatory. My Svg 
Score Extensions [1] document provides some comments too.
Common Western Music Notation defines things like "system", "staff", 
"voice", "chord" etc.
Non-Western musics would define things with other names, that nest in 
their own ways.

I'm not sure that I really understand Zoltan's profiles, but I could 
well imagine them describing different levels of implementation of CMN, 
which would be expressed in different CONTRACTs. For example, the 
parsing application should only look for grace notes if they are 
actually included in the CONTRACT. I imagine that some parsing 
applications might need to be told which notes are grace notes, in order 
to do something special with them. My apps dont use grace notes...

Apropos /Separation of responsibility/. Note that the CONTRACT contains 
no units of measurement. No pixels, no milliseconds. Those are only 
included in the INSTANCEs.
And the parsing application knows when it is reading temporal info 
(milliseconds), and when it is reading spatial info (often pixels).

All the best,
James
[1] https://github.com/notator
[2] http://james-ingram-act-two.de/open-source/svgScoreExtensions.html
[3] 
http://james-ingram-act-two.de/open-source/assistantPerformer/assistantPerformer.html

=================================================