ksr

- Browsing by geographical area / time period. I love the Radiooooo UI https://app.radiooooo.com/

- Getting specific recommendations / playlists from friends or web people I trust

Right now, I use node-isbn https://www.npmjs.com/package/node-isbn which mostly works well but is getting old in the tooth.

Résumé/CV: https://blog.karimratib.me/assets/CV-KarimRATIB.pdf

Email: [email protected]

I want to be hired to build Web-based music applications. I have very good experience in this domain, currently working on extending the open source music engraving engine Verovio with support for microtonality and better MusicXML import.

See my work at https://blog.karimratib.me/

As an entry point, I recommend checking out the "progress report" I wrote last October: https://blog.karimratib.me/2024/10/01/music-grimoire-progres... - I'm currently drafting this year's update. My main demo is at https://blog.karimratib.me/demos/musicxml/

1. In my own similar library (https://github.com/infojunkie/scalextric) I decided to pragmatically throw an exception if the transpose method is called on an untransposable scale... At the moment I'm not trying very hard to handle all the cases of transposability - I'm sure there's a mathematical object like a group or ring to describe such cases.

2. I'll read your code to understand better how you handle sub-scale sequences. I would like to revisit my own approach to start at the dyads (sequence of 2 tones plucked from a given tuning) and build up longer sequences from those. I think this would allow to distinguish between ascending and descending sequences in a natural way.

3. I've spent quite a bit of time with MusicXML, and some time with MEI as well.. Yes, neither format has a model for arbitrary tunings which is a glaring gap. MusicXML does represent the full set of visual accidentals (including custom SMuFL glyphs) as well as per-note decimal pitch alterations that can accommodate any cent value. MEI also represents a reasonably complete set of accidentals although it's a closed set, as opposed to MusicXML's open set of accidentals. MEI supports a few pre-defined tunings which also falls short of generality. In addition, MEI does not support per-note pitch alterations, which makes it even harder to represent anything outside the tunings that it pre-defines.

There's unfortunately little activity to update these formats to include general tunings. I'm having discussions in both communities, maybe you'd like to add your voice: https://github.com/music-encoding/music-encoding/issues/1167, https://github.com/w3c/musicxml/discussions/586.

4. I've also spent quite a bit of time on MIDI microtonality... There are 3 main approaches that I'm aware of:

a. MIDI Tuning System which maps the 128 MIDI notes to arbitrary frequencies.

b. Pitch bending which has the limitation that you mentioned above. MPE is essentially an organized methodology for reusing empty MIDI channels in a round-robin fashion for pitch bends and other controller effects.

c. MIDI 2 supports per-note controller settings out of the box, thereby superseding MPE.

My current focus is to create a MusicXML => MIDI conversion pipeline that supports arbitrary tunings, using Verovio as the MIDI conversion engine. I am of course "inventing" new MusicXML elements to represent these tunings and their mappings (and MEI elements too, because Verovio represents its own internal state based on MEI). My aim is to produce a MIDI version of the canonical Sagittal Example (https://www.sagittal.org/exmp/index.htm) from a MusicXML file.