1.0.0 release

[jaredjj3]

@eliot-akira, how is your experience using the library? What do you think it'll take to hit 1.0.0?

[eliot-akira]

Hi! Thanks for including me in the thinking process.

So far I've been using vexml's util/xml more than musicxml itself. I think this is because my use case currently is learning to generate and manipulate dynamic scores, with MusicXML being an intermediate representation I need to pass to vexml to render the score.

For this purpose, the methods in util/xml seemed more direct and easier to work with, to convert the data structures from my application into a MusicXML document, like:

const score = musicXml(scorePartwise({
  partList: partList({
    scoreParts: [scorePart({ ... })]
  }),
  parts: [
    part({
      id: 'P1',
      measures: [
        measure({
          attributes: [attributes({ ... })],
          notes: [
            note({
              type: type({ ... }),
              duration: duration({ ... }),
              pitch: pitch(({ ... })
            })
          ]
        })
      ]
    })
  ]
}))

const vexml = new Vexml(score)

I'm sure the equivalent is possible with musicxml, and I can imagine there would be advantages to using musicxml/elements instead of vexml/util/xml.

The elements in musicxml are thoroughly typed, documented, verified with schema, and provide methods to get/set defined attributes and values. There's good developer experience with editor "intellisense", where available methods and properties are suggested automatically.

So I plan to explore using musicxml objects directly as data structures in my application, instead of converting to/from plain JS objects.

---

It does seem to be a common question, this serializing to JS/JSON and back. I was reading a discussion recently that referred to this topic.. Ah, here it is, in the context of score editing.

• Create mechanism to programmatically navigate rendering vexml#158

  ..direct input/editing rather than string/file-based input

  ..there is a big need for a js level format to facilitate manipulation that can be piped back to tools like vexflow for a UI.

  ..some common theory operations like transpose, in a rendering-agnostic format

So this is more about "music objects", with a different purpose and scope than MusicXML objects. But I'm encountering a similar question for my use case, which is about dynamically re/generating a MusicXML document as the corresponding music objects change.

---

For example, say I'm writing a page of a music textbook online. I have a scale, a set of intervals, from which I'd like to generate exercises: scores playing the scale starting from each of the twelve chromatic notes.

In this situation, I think it's inevitable that I'd have to convert from some kind of music objects to MusicXML objects, instead of working directly with the latter.

A function to transpose a set of notes would be easier if the note objects were independent of MusicXML. Similarly, if we want an audio player that plays the score, those same note objects can be used as player events.

---

I wonder what's the common thread in these topics..

• Cursor to navigate the rendered score
• Audio player for score parts
• Score editor
• Programmatically generating scores for exercises, etc.

These are independent of MusicXML, or the score renderer (mostly). They have their own data structures, which must be converted to or from MusicXML. In the case of the cursor, convert from MusicXML to cursor-specific model(s). For the audio player, it doesn't need to know anything about MusicXML, but the player events do have correspondence with a rendered score.

So it's about conversion. And how MusicXML fits into a larger context of other musical features which have their own data structures. This may suggest a need for a higher abstraction of "music objects" that are designed for ease of use across these related domains.

---

About musicxml version 1.0.0, the library seems full-featured and stable, with a well-designed public interface. The thorough detail of lib/elements, how every element and attribute is modelled and documented, I think will be useful for many people.

A tiny detail: vexml uses the naming MusicXml, whereas musicxml uses MusicXML.

I wonder about the relationship and overlap between vexml and musicxml. I suppose theoretically the former could use the latter internally, but maybe there's an advantage to keeping them separate.

[jaredjj3]

Thank you for the extremely thoughtful response! I've been a bit busy, but I intend to respond to everything you said soon.

[jaredjj3]

So far I've been using vexml's util/xml more than musicxml itself.

I'm glad you're finding vexml's util/xml useful. I think you're doing the right thing by opting for a simple solution until complexity is warranted. If/when you come across this point, I'm interested in hearing about it.

For what it's worth, I think you can express XML using the following types:

type XMLNode = XMLElement | XMLText | XMLComment;

type XMLElement = {
  type: "element";
  name: string;
  attributes: Record<string, string>;
  children: XMLNode[];
}

type XMLText = {
  type: "text";
  content: string;
}

type XMLComment = {
  type: "comment";
  content: string;
}

type XMLDocument = {
  declaration: XMLDeclaration;
  root: XMLElement;
};

type = XMLDeclaration {
  version: string;
  encoding?: string;
  standalone?: boolean;
}

The main reason why I'm not using @stringsync/musicxml in vexml testing is because I wanted to purposely generate invalid MusicXML documents for testing. This library coerces invalid XML nodes, so it didn't fit my use case.

@stringsync/musicxml also doesn't support parsing partial documents at the moment, which would be needed to keep vexml tests scoped. I'm not sure how feasible this is, since some elements can appear in different places in the doc. Figuring out which tag to parse is simple, but figuring out what context that tag is in is difficult.

As for parsing in vexml, I wanted to keep the bundle small, which is another reason why I didn't adopt @stringsync/musicxml in it.

---

So this is more about "music objects", with a different purpose and scope than MusicXML objects. But I'm encountering a similar question for my use case, which is about dynamically re/generating a MusicXML document as the corresponding music objects change.

This may suggest a need for a higher abstraction of "music objects" that are designed for ease of use across these related domains.

You have the right idea. MusicXML is too cumbersome to interact with directly. You need to have a layer that speaks the domain language more fluently in order for developers to be productive. This has been my approach in vexml — the data layer is separate from the rendering layer.

I think vexflow EasyScore does a great job at speaking the music domain language, but as we both know, vexflow objects aren't really great data transfer objects. There isn't any software that speaks in raw "vexflow", so you'd be limited on what software can share it.

Something that naturally happens with higher level abstractions is that you have less control than working with the lower level objects. In stringsync/vexml#179 (comment), I discussed how vexflow has a Factory abstraction that takes care of instantiation, formatting, and rendering, but I don't think this is the right balance for something as general as vexml. I want vexml to be in charge of formatting, so I can instantiate objects in ~whatever order I want. I think striking a good balance between productivity and control will be one of the most difficult things in this music abstraction.

This isn't something I'd be able to tackle in a while, but I'm definitely interested and I would love to contribute to whatever solutions you come up with. Please let me know how I can help here!

---

About musicxml version 1.0.0, the library seems full-featured and stable, with a well-designed public interface.

Thanks for the feedback! When I find some time, I'll make a 1.0.0 checklist (mostly logistics stuff), comment it here, then publish it. I realize that some people may be reluctant to use this library due to the warning plastered front-and-center of the README.

---

A tiny detail: vexml uses the naming MusicXml, whereas musicxml uses MusicXML.

Haha, thanks for calling that out — that must be my internal style guide subtly changing. I think I'll conform vexml to use MusicXML :) It doesn't help that even WebAPIs kind of mix the naming conventions (e.g. XMLHttpRequest).

[eliot-akira]

I appreciate the thoughtful reply - I've been thinking about the ideas you raised, and exploring them in my project whose previous version used OSMD. I'm seeing how vexml and stringsync/musicxml fit into my use case, and for the latter I've been mostly using the generated and exported types (but not so much the class wrappers with get/set attributes).

Anyway, I have various ideas from experimenting - such as extracting MIDI (or player events) from MusicXML; and cursor overlay - and will definitely come back to this repo, or vexml/vexflow repo for hopefully more of this kind of fruitful dicussion. Thanks!