[college_physics]

Its a very cool project but as I have seen some other cool efforts as well, I feel that the domain of "open source computer-assisted music theory tools" is quite fragmented and people must reinvent wheels.

I wonder if we could imagine some sort of community project that abstracts certain music related objects (scales, chords) and representations and allows e.g. CLI or web-based rendering using possibly different stacks, interfacing with musicxml, lilypond etc.

Something like the "Grammar of Graphics" but for Music Theory

[chaosprint]

how about https://glicol.org

[college_physics]

thanks for the pointer, though from a quickscan this is not really a music theory tool but more like supercollider in rust?

[follower]

> abstracts certain music related objects (scales, chords)

I've been thinking about that again recently & attempting to resist both creating such an abstraction and re-inventing the wheel. :)

The first format that came to mind for its cross-language potential was essentially "Music Theory expressed in JSON format".

Yesterday I did another search for what current options there might be and after a very circuitous path ended up on an old version of the Tonal Javascript library I've already been using. :D

Specifically:

* https://github.com/Cycling74/node-music-theory/blob/518babe7...

* https://github.com/Cycling74/node-music-theory/blob/518babe7...

But the next abstraction level of associated "operations" (as documented by e.g. https://github.com/Cycling74/node-music-theory/blob/518babe7...) are still expressed in Javascript.

My impression is that there are a few tensions that complicate the creation of a "universal" cross-language/tool solution:

* Static vs dynamic storage/representation. e.g. Do you statically store the set of notes in a scale or store the intervals & the operation(s) needed to generate the result dynamically? e.g. https://github.com/Cycling74/node-music-theory/blob/518babe7...

* Reuse vs reinvention (time taken): When starting out it seems the amount of Music Theory most people want to use & have encoded is quite small. So initially the time required to "re-invent the wheel" is quite small vs time required to find & use a common shared abstraction.

* Reuse vs reinvention (knowledge gained): I know, for me, part of the motivation related to re-inventing the wheel is I also want to learn aspects Music Theory so I can understand/apply the knowledge in potentially non-programmatic contexts also.

I do think there is value in having the knowledge encoded in some manner so it's at least available for re-use for those who want it.

Edit #1:

> and representations.

In relation to the aspect of representation, my recent explorations introduced me to the following projects which might also be of interest to you or others:

* MNX - "representing music notation as machine-readable data" (intended as improvement of MusicXML): https://w3c.github.io/mnx/docs/

* Standard Music Font Layout (SMuFL): https://w3c.github.io/smufl/latest/index.html

* Verovio - "music notation engraving library": https://www.verovio.org/

FWIW my experience with SMuFL & its reference font(s) "Bravura" and "Bravura Text" (https://github.com/steinbergmedia/bravura/releases) was...mixed. Primarily because the emphasis (& use/testing) really does seem to be on the use of "Bravura" within notation software rather than "Bravura Text" which is intended for use in e.g. text editors.

But, for example, it is "Bravura Text" that (seems to) offer the inviting niceties of easy Unicode-based combining of head + stem + flag and/or vertical placement of notes on a stave.

Until, for example, you want to use one of the "note name" heads and discover that (a) they don't work with the stem/flag combining characters; and, (b) they're 7-10% larger in size than the default note heads.

Or, you find that the "latest" v1.380 "release" actually seems to be missing the entire ligature table that makes the vertical positioning feature work and you actually need to use the unlinked two year-old v1.392 "pre-release" instead.

(And that seemingly all the other "Text" variants of "SMuFL-compatible" fonts don't actually include any of the niceties that make it appealing.)

Err, excuse the rant, the wound might still be a little bit raw. :)

Anyway, hope some of this might be useful.

Edit #2:

Meant to add that, in my case[0] at least, I think it would have been better to initially make use of the standard Unicode Music Symbols block (https://en.wikipedia.org/wiki/Musical_Symbols_(Unicode_block...) via Noto Sans (https://fonts.google.com/noto/specimen/Noto+Music) rather than deal with a SMuFL-compatible font.

[0] A 7-day game jam entry created with Godot 4: https://rancidbacon.itch.io/stave-off