Devlog #1: ughhghgjhgjhhh

Sumary: I have added (extremely basic) MIDI input, tidied up and planned ahead some more, and spent hours debugging why my code failed to parse a file which turned out to be corrupted :)

The day after writing my first devlog, I started sketching out a more comprehensive relationship between the MusicXML parser and OSMD renderer. This led me to realize that my previous approach for the entire scoring engine is fundamentally incompatible with like.. playing the piano as a human being. I have since modified it and I’m very confident what I’m currently making will work.

Also, I wanted to start working with real scores, so I got a few MusicXMLs with permissive licenses off MuseScore (massive thanks to those who write them!) and tried importing them… it failed. I must have spent a solid 3 hours trying to debug my previously-functional code before even considering the file might be corrupted. Turns out, I opened it with VSC at some point (massive thanks to Windows for breaking my line endings!). You can see the new-successfully-parsed file in the screenshot attached :P

Last week has been packed and I couldn’t work much, however I have some good news! I’ll be away from home for a while and won’t have my MIDI keyboard, but a friend agreed to borrow me his! They’re much better at playing than me so they also agreed to play-test and provide feedback once I have a demo ready :)

See you in the next devlog!

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:

1. I love music and difficult video games, so naturally I love rhythm games.
2. I love playing the piano (despite sucking at it) and really want to learn how to sightread.
3. 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!