Re: Getting Off The Ground

Dear Joe, Michael, Daniel and CG Members,


To introduce ourselves; Bob is the co-founder and technical lead of
neoScores.com. Hans is our first employee who now almost exclusively is
involved with our rendering engine which reads and displays MusicXML (and a
bit of MEI). Vincent is in charge of checking the semantical quality of our
“incomming” MusicXML-files we get from publishers.

We (from neoScores) attended the last three "MusicXML community meetings"
where we also proclaimed to start collaborating more tightly on the
evolutions of the MusicXML- (and SMuFL) -standard. So, here we are.


To answer Joe’s initial questions for “what’s next?":

We agree on your major goals. However, previous reactions point out that we
definitely need to document music notation use cases first before we
continue.


In our opinion, we believe this CG has a fundamentaly other scope than what
MEI tries to do. We have the need for a specification that can be improved
fast, which is lightweight but concise and semantically correct. A
specification that is easy to read, easy to convert to other formats (json)
and is used in applications with a wide support. And most importantly … it
should be unambiguous and strict.


Therefor MusicXML as a standard is, in our opinion, definitely the optimal
starting point. Not only because the MusicXML-community-group started this
W3C-CG, but formost because it is already there in every aspect we just
described. MusicXML has some issues and oddities… But if we compare it (in
our experience) with MEI, MEI is more usable as an archiving specification
and not ready yet to be used as a specification to work with in a
production application, especially when it’s an interactive one with DOM
manipulations.


On the other hand, there are some aspects in MusicXML which definitaly
should be addressed (“backup" and “forward”, eg...), but to fix this, we’ll
need to drop backwards compatibility.


About SMuFL, we agree there is no fundamental discussion required and
should be incorporated in the MusicXML-spec.


What would we most like to see done with MusicXML right away?

- SMuFL!

- Drop backwards compatibility to fix legacy problems, but also talk about
XSLT-schemes or software-tools to  migrate “old” to “new” MusicXML.

- Add more semantics

- Start talking about css-alike specifications

- Do some marketing towards the major score-editing tools to let them do
their exporting-jobs a bit better ;-)


All the best,


Bob, Hans & Vincent

Bob Hamblok


*CTO - Co-Founder*neoScores, the digital alternative to sheet music

bob@neoscores.com
mobile +32 476 74 78 42
http://bhamblok.io | @bhamblok <https://twitter.com/bhamblok>

Visiting address: Startit @KBC, Eiermarkt 20, BE-2000 Antwerp, Belgium
Invoicing address: neoScores NV, Pluyseghemstraat 19, BE-2550 Kontich,
Belgium
VAT BE 0536.406.040

Follow us on: neoScores <https://www.neoscores.com/> | Facebook
<http://www.facebook.com/neoscores> | Twitter <http://twitter.com/neoscores>

On 19 September 2015 at 03:54, Dennis Bathory-Kitsz <bathory@maltedmedia.com
> wrote:

> Hello,
>
> I am a composer some of whose work involves graphical notation, with some
> graphics embedded in traditional notational practice and some almost
> entirely
> outside it or independent of it -- yet still being a musical score. A great
> amount of music using graphical notation (including animated notation, 3d
> content, graphical rendering of electronic content, etc.) is being created.
>
> How capable or extensible are these tools in handling newly developing
> notation? I would refer to the book Notations 21
> <http://www.amazon.com/Notations-21-Theresa-Sauer/dp/0979554640> or, as an
> example, the third sample group on this page
> <http://maltedmedia.com/people/bathory/engraving.html>
>
> On the Finale list, this question has come up occasionally.
>
> Thank you,
> Dennis Bathory-Kitsz
>
>
>
>
>