2 KiB
Typing system design
This document talks about how data flows through the system, and how it's displayed, so that users can enter text using a MIDI device.
There are a few distinct pieces:
- data flow: how do we get from MIDI to the display and to the typing portion?
- encoding: how do we represent text so that we can enter it?
- parsing: how do we read a MIDI stream to convert it into our text encoding?
- display: how do we present the state to a user so that they can see what they're doing?
Data flow and architecture
We already have the ability for data to flow in, and for devices to be added and removed. What we need here is another piece that will keep track of state for the typing daemon.
The typing daemon will be a state machine, with state transitions for entering new bits and for emitting text (which will then move back to a clear state).
It will be subscribed to all incoming MIDI messages, and it will store a separate state for each connection ID, so things you enter on the drums will not alter what you're entering on the wind synth, for example.
It will emit text directly, via enigo (or, in debug mode, to the console).
And it will emit its current state on another queue, which can be used to
display the characters which can be typed.
Encoding
Each MIDI device will be in a given base. Wind synth will be in base 11 by default, so we can read the semitone and ignore which octave it's in. We could expand this to use a wider range, or narrow it to belong to a particular key, but this is the starting point. Drums will be in base 2 by default, with the snare and kick drum providing the bits and everything else being ignored.
We will support a given range of characters, and some modifiers as well. Other keys can be added, but this is where we'll start: just text! the characters supported initially will be 'a'..'z', 'A'..'Z', '0'..'9', '.', and ','.
Each of these will be assigned a number, which will then be converted to base 2 for entry.
Display
Given a list of