Re: Requirements Matrix and Architectural Proposals

Hi all,

Nice to have seen you all and thank you Michael, Daniel and Joe to be the chair holders of this group. You make a great team.

I strongly support the vision of separating the Semantics, Visual/Layout and Performance Facets of Music Notation into multiple formats as well as into multiple file resources.
Even if the format of the Visual/Layout- and the Performance-facet will look very similar, it should be possible to “require” them from multiple resources. It’s like separating UI from functional logic, but with a third dimension. In the end, this will allow the end-consumer to make an easy “switch” to another setting related to his wishes.

I also agree we need to discuss the architecture without mentioning specific standards.
I have to say though, in my humble opinion, in the near future there won't be a lot of difference in “coding for the web" vs “coding for native applications":
- The browser is nothing more than the runtime environment, just like an OS or like JRE for java...
- The future (draft) Ecmascript-specifications will allow “web"-developers to "touch the metal”, just like “native"-developers.
- All languages are converging. Lets be honest, the “native" Swift-programming-language starts to look a bit like javascript while Typescript looks a bit like C. Frameworks like Facebook’s “ReactNative" is one of the examples to close some gaps between web and native.
- Let’s not forget more and more end-consumers have only one or more mobile devices which run "the web".
- …
Concluding: having a DOM as a container for the semantics is a great leap forward, which we can enrich with “stylesheets” and “performance sheets”.

One question though (not being a native-english speaker): Is “performance” the best term to be using here?
As a musician, YES. But our computers and devices will never be musicians :-)
As a developer, I associate this word with the speed of processing-power. Isn’t the distinction we try to make here, the “audible” facet in comparison with the “semantical" and “visual” facets? In a later iteration we could add the “performance” facet, once again in a separated format, when we are ready to add choreography :-)

Best regards,

Bob Hamblok
CTO | neoScores

EMAIL bob@neoscores.com
PHONE +32 476 74 78 42
SKYPE BHAMBLOK

www.neoscores.com
https://www.facebook.com/neoscores| Twitter

Gustaf  More room for music.

VISITOR ADDRESS Startit @KBC, Eiermarkt 20, BE-2000 Antwerp, Belgium
INVOICING ADDRESS neoScores NV, Sleutelstraat 13, BE-2550 Kontich, Belgium
VAT BE 0536.406.040

On 9 April 2016 at 13:40:40, James Ingram (j.ingram@netcologne.de) wrote:

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 (AA), that creates an instance of a score (INSTANCE).
The INSTANCE is parsed by an application (PA) that does something with the contained data.
AA makes a contract (CONTRACT) with PA 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]):
AA 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 PA'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