Re: Proposal for Encoding Common Musical Notation in Unicode

Hello Snake,

Yes, that is surely a very practical approach, I was just wondering whether
it would be considered as sufficient to prove what we can, or cannot do,
with this encoding. As an important target is to write composite documents
(write a line then break out with a staff then continue your discourse), it
would not show much with this regard.

Anyone here, what do you think?
FYI I also considered using verovio with a python parser, I considered
excel ("if all you have is a hammer, everything looks like a nail"), and
forking MuseScore to let copy and paste as Unicode.

I started to do exactly what you propose and stopped early: I do not know
how to write a parser (there can be 1 to -say- 6 characters for a single
note, a few control characters, and I need to keep track of the current
position... I am not sure how to achieve that, I am at regex and substr
level of string parsing). I am not sure either how to write xml out
(efficiently, I mean), and I am not sure of the minimal requirements to
create some valid mnx.

Again, anyone knowing how to do this and willing to participate is welcome.
You may guess that my current process is far from efficient.

Regards,
Bertrand.

On Sat, Sep 5, 2020 at 7:24 PM Snake <snake@downtoearthsolutions.com> wrote:

> Hey Bertrand,
>
> Maybe writing a parser that creates MusicXML is the easiest approach, then
> you don’t have to worry about rendering or playing back the notation, just
> import the MusicXML into an existing notation program.
>
> Snake...
>
> On 6 Sep 2020, at 3:09 am, Bertrand Emerit <bertrand@emerit.com> wrote:
>
> Dave,
>
> Thank you for your feedback. I mentioned ABC in passing as one of the
> textual notations of music. I thank you for the links, I had never
> considered how rich this notation is.
>
> It looks to me as having globally the same pros, and cons (depending on
> the use case), of other standards, aiming to code music and not the
> graphical representation of CMN. There is a strong position that makes it
> slightly apart from other standards, namely "Abc is above all a language
> for describing music and so there should be clear separation between
> content and any formatting information" (in the route-map
> <http://abcnotation.com/wiki/abc:standard:route-map>). I agree with you,
> the programmers probably have some very useful experience to build upon.
>
> Regards,
> Bertrand
>
> On Fri, Sep 4, 2020 at 9:46 PM <dave@mozart.co.uk> wrote:
>
>> Bertrand,
>>
>>
>>
>> It may be worth noting that there is already a scheme for encoding music
>> notation in text (in this case ASCII): called abc.   The spec is at
>>
>> http://abcnotation.com/wiki/abc:standard:v2.1
>>
>> http://abcnotation.com/wiki/abc:standard:v2.2
>>
>>
>>
>> abc has a small but enthusiastic following, and there are (free)
>> applications available for drawing the music.
>>
>> It isn’t quite what you envisage, and the drawing code still has to make
>> all sorts of assumptions about the placement of symbols.   But it may be
>> worth referring to, as the problems encountered by people who have
>> programmed it, may anticipate some for your system.
>>
>> Dave
>>
>>
>>
>> David Webber
>> Mozart Music Software
>> http://www.mozart.co.uk
>>
>>
>>
>>
>>
>>
>>
>> *From:* Bertrand Émerit <bertrand@emerit.com>
>> *Sent:* 01 September 2020 00:47
>> *To:* Daniel Spreadbury <d.spreadbury@steinberg.de>; Michael Good <
>> mgood@makemusic.com>; Joe Berkovitz <joe@noteflight.com>; Perry Roland <
>> pdr4h@eservices.virginia.edu>; W3C <public-music-notation@w3.org>
>> *Subject:* Proposal for Encoding Common Musical Notation in Unicode
>>
>>
>>
>> Dear ladies and gentlemen,
>>
>>
>>
>> On September 30th I plan to submit the attached proposal to the Unicode
>> Consortium.
>>
>> Unless you ask differently, I intend to Cc you of the mail, while making
>> plain in the body that this is for your information, as you are mentioned
>> in the document, and in no way an endorsement.
>>
>>
>>
>> I will be honoured for any review or comment of the documents. Feel free
>> to forward as needed, and I would appreciate that you inform me if you
>> forward outside your organization.
>>
>>
>>
>> The proposal should fit nicely if not enrich (and certainly not make a
>> dent in, or replace) your current works, including SMuFL, MusicXML and MEI.
>>
>>
>>
>> Best regards,
>>
>> Bertrand EMERIT
>>
>> +33672966996
>>
>> bertrand@emerit.com
>>
>
>

Received on Saturday, 5 September 2020 20:52:37 UTC