SongMapStore

Where finished song maps are kept between runs of an application.

A scan of a whole song costs seconds of processor time, so a song that was played before should be mapped from its first note rather than scanned again. The visualiser holds the newest maps in memory by itself; a store is what survives the process.

The application owns the location, because only it knows which of its directories may be cleared by the system and which are backed up. SongMapStore.inDirectory is the ordinary answer; an application with its own database may implement this interface instead.

A key is opaque and already carries the analysis version, so maps from different versions never collide. It contains slash characters, which a store that names files after keys has to replace. The bytes are the visualiser's own format: write them back unchanged, and answer null rather than throwing when an entry is missing or unreadable.

Calls happen on a background dispatcher, never on the analysis worker, so they may block.