Skip to content

README.md

Latest commit

 

History

History
55 lines (35 loc) · 3.65 KB

README.md

File metadata and controls

55 lines (35 loc) · 3.65 KB

Introduction

This is the JSON schema that goes along with Smoosic. Smoosic is an open-source music editor written in typescript.

The 'Smo' in Smoosic stands for s erializable m usical o bjects. It is the storage format for the Smoosic application, or maybe Smoosic a demostration of the SMO specification, depending on your perspective.

Let me just start off by saying, I don't know if there are already better JSON schemas for music. I did a bit of searching, and I didn't find anything specifically intended to store the contents of a score for the purposes of notation, which is the primary purpose of Smoosic.

About SMO

Is it SMO or Smo? I usually use the later, although it is an acronym.

Repository Files

smoosic-schema.json  - the schema
tools/
  validate.js  - validates a score against the JSON schema
samples/
  jsonScores/
    - contains sample scores that have been validated against the schema
  sampleSchema
    - Some json schema samples that I found useful (not specific to Smoosic)

To run:

node ./tools/validate.js /path/to/myscore.json

Goals

The goal of SMO was to capture an abstract representation of music in a way that would be familiar to anyone who is familar with both music and programming languages.

As an example, let's say I wanted to make a container of measures, but not part of a full score, to store selections or snippets. Or define a selection of music that could be shared between applications. How would I do this in Music XML? I suppose you could create stylesheets, etc. that create a new schema out of parts of the existing, but there's really no way to validate against both at the same time.

Partially because of the simpler format that JSON offers, and also because of the flexibility of JSON schema, you could produce your own versions of these things, in your own type of container. Or you could choose to implement a small subset of SMO in an application, since there are reasonable defaults for almost everything. You can read scores and focus on only the bits you care about.

Requirements

This json schema should be:

  1. A formalized specification for interperability and validation, that can also be extended and mixed with other schemas.
  2. A modular, scalable schema. The JSON defines containers at many levels, so you could serialize a note measure, group of measures, stave, or a full score and it still validates. This is used in the applicaiton in cut/paste and undo, but could be used between different applications, or as storage.
  3. Simple to implement. Whereve possible, entities should contain reasonable defaults. So you could implement a very small subset and still be valid in the schema, and useful for your application.

In music notation, there is always some abiguity, e.g. if the measures have differemt numbers of beats. The specification doesn't specify how these are to be handled.

Schema Status

My first attempt at serilization was to just take the saved score, and JSON.stringify. But this has the problem of duplicating a lot of information such as key signatures, which creates a lot of confusion in the code and makes the schema a lot bigger than it ha to be. It makes more sense to have time and key signatures in a map, and the map concept applies to other entities such as instruments and parts which were added later.

There are some things I'm indecisive about. Mangling 'Smo' into objects like 'Note' make sense for the code, to avoid namespace conflicts. But is it needed for a schema that already has a namespace?

Currently, SMO is stored with a dictionary to compress file size. This is not part of the speciifcation, and it may not be the best way to compress file size.