Devlog #0: Let’s begin!

Summary: I’ve researched and planned ahead, created the project and GH repo, and started work on the core engine (OSMD).

This is an introductory devlog which aims to provide some context for what’s about to follow, as well as document the first steps of creating the project. This one in particular might be rather long.

First, you should know a few things about me:

I love music and difficult video games, so naturally I love rhythm games.
I love playing the piano (despite sucking at it) and really want to learn how to sightread.
I love programming and game development (among many other things not worth listing here).

These 3 insights should explain how the idea of making a rhythm game about sight-reading sheet music with a MIDI keyboard popped into my head a few years ago.

I’ve participated in Hackclub’s “Summer of Making” event last year, though I didn’t ship anything unfortuantely. I figured the rhythm game idea would be nice for this year’s participation (flexible scope, good mix of familiarity and unfamiliarity, fun) so here I am :)

So far around 15 hours were spent planning and RTFM’ing: I was initially consdering building a standalone program in Godot, but settled on the web because of the existence of several libraries/dependencies that do most of the heavy-lifting for me (and accessibility). My stack is Vite + Vanilla TS due to familiarity.

I picked the name “Clavistry” (Clavier + Artistry) among many much sillier candidates, such as: Prima Vista, Etudio, Ledgerdemain, (No) Accidentals, Sightreader, Claviator.

The project will be split into the following components:

OSMD engine (MusicXML parser, render, moving cursor)
Web MIDI API (interface with MIDI keyboard)
Scoring engine (compare OSMD expected input and MIDI user input)
Feedback/UI
.mscz converter (Clavistry uses MusicXML, this allows importing from MuseScore)

They’re roughly placed in order of importance, and now I’ve started working on the OSMD engine itself. More on that in the next devlog :)

P.S: I’m new to actively documenting my work like this, and I plan on keeping subsequent devlogs shorter. Thanks for taking the time to read through this!