I'd like to deploy an MVP version of this application today, so I'm dropping
support for a few features to focus my efforts. I may bring these features
back.
TL;DR:
- Temporarily drop support for "Fine Tune" tab of preferences
- Sort keys by the Circle of Fifths
For now since I'm the only customer and I'm primarily making this for myself,
I'm styling the app specifically for my Google Pixel 4. If I find this app
useful, I will consider supporting other devices.
I'm using the Icons that I bought when I purchased the "Refactoring UI" book.
Other news:
- I bought the domain learnpianochords.app!
What's left:
- Style the "fine tune" tab of the preferences view
- Better support non-mobile devices like the browser and tablet devices
- Deploy the application to learnpianochords.app
- Redesign the "key" tab of the preferences view to sort the keys according to
the circle of fifths
- Dogfood
- Simplify until I cannot simplify anymore
Start styling the Chord Drill Sergeant for mobile devices because that is that
device on which I will primarily use CDS.
I'm also deleting the debugger related code. I would like to support a debugger,
but I'm not currently using this one, so I am going to remove it to keep things
slender.
- Introduce TailwindCSS, which also introduced elm-live, index.html, index.css
- Add mobile-first styling for the preferences modal
- Remove unused code
Generate chords for a given key.
I believe my Theory.allChords function is taking a long time to generate all of
the chord possibilities. I would like to profile this to verify this
assumption. I think I can create a "staging area" for changes and only
regenerate chords when "committing" the options from the "staging area". This
should stress the application less.
TODO: Profile application to find bottleneck.
For the past two to three days, I've been searching for the name for the concept
of "C" or "A". From what I read, notes are specific things like C0 or C4, but I
wanted the name of the concept of a C. Thankfully today I discovered that this
is called a pitch class.
While I did change a lot of functionality, I also ran `elm-format` across the
codebase, which makes these changes a bit noisy.
Here is the TL;DR:
- Properly support chord inversions
- Ensure that the piano styling changes dynamically when I change the variables
like `naturalWidth`
- Add start and end notes to define the size of the piano and which chords we
create
- Support elm-format and run it across entire project
- Debug Misc.comesBefore
- Introduce a ChordInspector and debugger
TODO: Ensure that we only generate chords where all of the notes can be rendered
on the displayed keys.
TODO: Add preferences panel, so that I can do things like "Practice blues chords
in C and E with chord substitutions."
Remodel application to support the scientific pitch notation for notes. Instead
of supporting simply "C", support "C4". This change created cascading
changes. After refactoring for around an hour, I restored the app to a working
state. The current state is not desirable, but it compiles. More changes on the
way.
Using BPM as the unit for tempo.
TODO: Consider a higher-fidelity way to calculate BPM, although I'm not sure
this is critical functionality; an interesting problem is just seducing me, and
this app would be better off resisting the temptation.
Elm reminds me of Haskell. In fact, I'm using `haskell-mode` (for now) in Emacs
to write my Elm code, and it works reliably. I'm not writing a Haskell app, but
if I were, I would define my application Model with the following Haskell code:
```haskell
data Model = Model { whitelistedChords :: [Theory.Chord]
, selectedChord :: Theory.Chord
, isPaused :: Bool
, tempo :: Int
}
```
When I first modelled my application state, I did something similar. After
reading more Elm examples of SPAs, I see that people prefer using type aliases
to define records. As far as I know, you cannot do this in Haskell; I believe
all types are "tagged" (something about "nominal typing" comes to mind). Anyhow,
Elm isn't Haskell; Haskell has cool features like type classes; Elm has cool
features like human-readable error messages and exhaustiveness checking for
cases. I love Haskell, and I love Elm, and you didn't ask.
Anyhow, this commit refactors my records as type aliases instead of types. I
think the resulting code is more readable and ergonomic.
Create a more convincing representation of the piano.
I would like to compute the left-offset based on the naturalWidth. That change
is probably forthcoming.
First of all, Elm's purity is beautiful. I think every language should model
their error messages and develop experience after Elm. If I didn't have to
download packages, I don't think I would need an internet connection to
troubleshoot my program's errors. This is how helpful I find the compiler.
Now that that's out of the way, here's what I've changed since we've last
corresponded:
- Use Elm's Browser.element to create a reactive application with state
- Write a function to generate all of the chords about which CDS knows
- Move some code out of Main.elm into other modules
- Depend on List.Extra, Random, Random.Extra
What's left:
- Lots of work
- Instead of clicking a button to show a new chord, use a timer
- Add mobile-first styling (probably add TailwindCSS)
- Persist settings in LocalStorage (and then eventually create user accounts)
- Allow users to curate the list of chords they're interested in practicing
- Deploy the website and dogfood it
Unknowns:
- How can I handle tempo? I don't expect setInterval to be enough (maybe it
is)...
Initialize an Elm application to build a MVP for the Chord Drill Sergeant
application. There isn't much to see at the moment. I'm just sketching
ideas. More forthcoming...
