Ameobea/web-synth

 * Added additional required dev dependencies like `@typescript-eslint/eslint-plugin` and `eslint-plugin-react`
 * Use `babel-loader` instead of `ts-loader`
 * Upgrade all dependencies
 * Migrate the `tslint.json` file to `.eslintrc`
 * Fix all new lint errors that popped up as a result of switching to eslint

 * Builds the backend and deploys it as a single binary inside of a Linux docker container

 * Handle all of the state stuff for that.

 * Create file uploader custom input for `react-control-panel`
 * Add it to the the control panel for the faust editor view
 * Set up logic for loading and playing the uploaded audio files
 * Connect up the created buffer source to the visualizer and connect that to the output by default

 * Uses an `AnalyserNode` to generate FFT from faust module output and renders it to a canvas as a heatmap.  Very classic Ameo stuff.
 * Update faust compiler to unescape quotation marks in the generated module JSON

 * Create a component that loads stored effects and renders them as a selectable list
 * Create a control panel that houses the list of effects and includes a button that loads them into the main code editor when selected
 * Add CORS headers to the backend
  * Roll it outself by just adding the HTTP header and responding with a 200 to any and all `POST` requests
 * Add in a very crude form for saving code to the backend

 * Get all of the pieces fit together again.  This was a lot easier than I thought it was; Rocket has come a long way since the last time I used it, and it's just awesome now.
 * Create configuration files with Rocket.toml
 * Set up migrations to bring up the database

 * Create some boilerplate Rust/Rocket/r2d2/diesel app for building out the framework of the application

 * This makes it much easier to handle persisting the instance's state when switching tabs, initializing its state when creating a new editor, and keeping it in state with the Wasm backend.
 * Separate out the code for building the UI and building the Faust instance into separate files
 * Fix a bug in the Faust compiler server where the wrong output filename was passed

 * Allow stopping the currently playing module and replacing it with a new one if different code is compiled
 * Make a new default set of views for the application when initializing from scratch including a MIDI editor and a Faust editor pre-filled with an example program from the Faust website
 * Upgrade all engine dependencies

 * Map the Faust UI definition object into control panel settings objects
 * Hook up the control panel's event listeners to the Faust module's `setParamValue` attribute

 * Read the created JS file and parse the JSON definition out of it with Regex
 * Add the JSON definition as a HTTP header to the response from the server that returns the raw Wasm blob
 * Set up CORS headers that allows the custom header to be read
 * Read the custom header on the frontend and pass it into the code that builds the module
 * Add some error messages when compilation failes and return them in the response
  * Add a display for the received error messages on the frontend
  * Return `stdout` in the case that compilation of the module fails
 * Add in custom types for the created Faust module that include the additional custom attributes added by the class

 * Include a script file from Faust that defines a class that can be used to transform the WebAssembly blob returned by the Faust compiler into a `ScriptProcessorNode`
 * Use that script and the class it defines to create a `ScriptProcessorNode`
 * Connect that `ScriptProcessorNode` between the microphone input and the output of an `AudioContext` we created
 * The result is live-transformed sound that gets played back.  We've basically created a mirror of the Faust playground, but we understand + control all the pieces and can extend them to play nicely with our existing pieces.

 * Creates a POST request with the current content of the editor
 * Returns a Wasm file containing the compiled output
 * Compiles the Wasm blob into a module and instantiates it

 * Was originally going to use a builder container with two alpine containers, but `faust` doesn't work in alpine and the binary built by go in alpine doesn't run on ubuntu, so we just build the whole thing in debian.

 * Base-bones Go project that reads Faust code via a single POST request endpoint and compiles the received file into Wasm using the `faust` command line.  Sends the resulting wasm blob as raw bytes.
 * Add very simple README.md file for the faust compiler microservice

 * Create a `dispose()` method on the `ViewContext` trait and implement it for `Grid` and `FaustEditor`
 * Fix the `reset()` method of `ViewContextManager` to properly delete and cleanup the old VCs and pull from the live VCM rather than its serialized representation (which apparently was often out of date)
 * The end result of this is that all of those `localStorage` entries got deleted.

 * Add a custom title attribute to VCs state
  * Switch up some of the struct/state organization for VCs on the backend
 * Add the ability to set a custom title for a VC by double-clicking its tab.
 * Add a delete button on VC tabs to allow them to be deleted

 * Fixed bug with state keys for grid data that were under different keys
 * Abstracted out note creation logic to helper function taking line index, start beat, and length

 * Create a UI element for displaying active VCs and allow switching between them.  Keep its state in sync with the real VCM at all times.
  * Shift the main document content down to make room for it.
  * Update input handlers to take this into account.
 * Update component rendering and mounting/unmounting/commiting to keep their states in sync.
  * Came up with a pretty good plan for how this is actually going to work.  The idea is that `cleanup()` will get called to clear the VC's state off of the screen but keep its state around.  We'll probably want to change up the way that we do stuff like hide the Faust editor to keep it around in the DOM but just hidden.  We could probably just do the same thing for the MIDI editors too, honestly.  Right now, we're keeping their `NoteSkipList` and everything but re-building their notes, but why not just swap out the canvas that they're rendered on?
 * Various other changes to state persistence
  * Keep editor state separated from the VC definition.  This allows us to be a lot more flexible with the way we handle saving and loading things.
 * Tons of other changes.

 * Remove duplicate handler function for saving all VCs to `localStorage` from `ViewContextManager`
 * Add function for getting current Faust editor state from JS and use that rather than the value in JS for saving the Faust editor VC
  * Change the `save()` method of `ViewContext` to take `&mut self` instead of `&self` to make this possible

 * Add a view context that will be used to edit and run Faust code directly from within the application
  * Uses `react-ace` to create a code editor
  * Calls into JS code to create and manage the view context (the Rust code is just a shim)
  * TODO: Handle state persisting and some other plumbing concerns
 * Create a view context switcher component
  * Creates new views using the `build_view` function
  * TODO: Handle loading view config and checking if existing views with the specified view name exist so that they can be re-used.  We have to think about how we want to manage persisting view context state when switching views locally.
 * Update a bit of the view context mounting stuff
  * TODO: Clean up the grid view contexts when they're unmounted.  This will probably just consist of dropping all of the child nodes of the canvases.

 * Split it up from all being under a single key to having "pointers" into other keys for the individual view context states.  This allows us to update a single VC without having to re-serialize all of the others.

 * Create some structs for holding global VCM state
 * Create functions for loading/storing global VCM state to/from `localStorage`

 * Set up grid and trait methods for the clip compositor
 * Add a bunch of default handler methods for some grid traits that just do nothing
 * Move the current grid renderer methods for the notes into being defaults for the `GridRenderer` trait