multiplayer osc message sequencer, receiver, and sound generator

• use webpack so i can structure my frontend code more nicely
• model and load channels in a way that's more maintainable and makes adding channels easier
• add some basic channel settings and ensure they're extensible
• add per-channel volume control
• start persisting channel config to a db (must be done entirely server-side) and loading from it on startup
• assign new connections a randomly generated username based on IP and include that username in the logs
• add effects to channels, or a way of adding/confguring effects
• quantize messages that trigger sound
• OPTIONAL (if possible): persist that username between sessions somehow?
• add some visual feedback on channels when a sound is produced
• change the way user names are set, so that messages from the inbuilt sequencer from different clients can be distinguished
• add a documentation nav bar
• remove sequencer (in preparation to move it to a separate project)
• add global settings (vol?? bpm??) to option groups in control channel
  • add bpm control
  • add global vol control
• add more voices to the instrument channels
• add some visual feedback on channels when settings are changed
• improve overall visual design
• add a message explainer (message spec docs page? on to the i/o panel?))
• try setting up again with bun
• typescript??
• get testy

• control channel (used to modify other channels)
• instrument channel with selectable voices
• synth channel with configurable wave & envelope
• effects channel (reverb)
• sampler channel with configurable samples for each note
• effects channel (????)

The messages all have to be ORCA comatible for no other reason other than that I like it and want to use it. ORCA only lets you send numbers, so osc-chat accepts only numbers.

Configuration is saved to the channels and not done live on each message to encourage interference between users.

Because messages are broadcast to all clients, any configuration changes are also broadcast to all clients. This makes it hard to persist configuration state between connections, because writing from the client side would result in multiple redundant writes. Instead, the server stores the most recent configuration message of each type, and sends them all as a batch to new clients when they connect.

always:

yarn install
yarn build

yarn run start

yarn run build:docker
yarn run start:docker

then go to http://localhost:8080 in your browser, or send OSC messages to localhost:57121

log in to the right aws account, then run:

yarn build
yarn cdk deploy