I want to build a large format, real-time, physical music visualizer that could orchestrate an artistic light symphony for any song.
I'm imagining physical visualizers that are columns of multiple, discrete light nodes, each able to have variable brightness and color.
The real-time music processing is the hard part (for me) to crack.
There's some standard tricks here: FFTs, bandpass filters, etc.
But I want to do more: Real-time stem separation, time signature and downbeat tracking, etc.
Imagine hearing Sweet Caroline and, when the horns kick in, the whole installation 'focuses' on the horns and bright yellow light jumps between each column on each horn note, before returning to tracking the bass line or something.
I've been noodling on this idea for a long time and slowly digging into the music and CS fundamentals. The rise of LLMs might finally be the piece that enables me to close my intelligence gap and finally build this thing...
- Setup VMs locally, on your development machine. (This eliminates the cost of hosting but gives you all the technical learning opportunities). My development machine is macOS and UTM has been an excellent app to manage these VMs. You can eventually model your VM's configuration around what resources your VPS will have on AWS/DO (e.g. 1GB RAM, 2 vCPUs, etc).
- Learn the basics of Ansible, in order to provision a server (local or remote). I did the course on KodeKloud.com and found it great to getting me going quickly.
- Write Ansible playbooks to provision your local VM as you would want your VPS on AWS/DO/etc to work. Ansible Galaxy is a repository of many community-supplied roles for common tasks/services. You could consult these for best practices on building your own playbooks or totally offload provisioning onto those roles.
- Once you're comfortable getting your local VM setup, point your Ansible playbook at an AWS/DO VM and put it online!
My high-level roadmap has been to build my own Ansible playbook to provision a Ubuntu server to CIS Level 2.
CIS benchmarks define security controls for a few of the more common aspects of DevOps work (e.g. Ubuntu OS hardening, AWS account security, Docker host, etc). They're freely available and there's many well-maintained scripts that can both audit and provision your host to the standard. I've been using the benchmarks as an easy to way to self-teach security aspects (and validate I've done it correctly). Level 2 is the standard used to handle financial information and medical records, so it's probably the most secure you'll ever need to go.
Once I have a provisioning playbook to stand up a secure host with some services (Nginx, Redis, etc), the next goal on my roadmap is learn Terraform to configure + deploy a personal cloud of services to AWS/DO/etc.
Similarly, Google purchased reCaptcha and ended up harnessing the stream of human interaction into that to, among other things, classify all of their Street View content (e.g. select the stop lights/bridges/license plates/etc).
Looking at the Beeper Mini announcement [1], they clearly state that a user doesn't need an Apple ID to register their phone number and send/receive iMessages. Also, they describe direct, device-to-Apple interactions.
However, this article says:
> IDS is used as a keyserver for iMessage...
> The first step in registering for IDS is getting an authentication token. This requires giving the API your Apple ID Username and Password.
> After registering with IDS, you will receive an “identity keypair”. This keypair can then be used to perform public key lookups.
So how does the Beeper Mini app take an arbitrary Android phone number, register public keys for it with IDS, and perform public key lookup of recipients... all without ever using an Apple ID?
EDIT - It looks like the answer here is the 'SMS Gateway' which is virtually undescribed in the OP article or anywhere on [1]. Guess that's the secret sauce.
I'm imagining physical visualizers that are columns of multiple, discrete light nodes, each able to have variable brightness and color.
The real-time music processing is the hard part (for me) to crack.
There's some standard tricks here: FFTs, bandpass filters, etc.
But I want to do more: Real-time stem separation, time signature and downbeat tracking, etc.
Imagine hearing Sweet Caroline and, when the horns kick in, the whole installation 'focuses' on the horns and bright yellow light jumps between each column on each horn note, before returning to tracking the bass line or something.
I've been noodling on this idea for a long time and slowly digging into the music and CS fundamentals. The rise of LLMs might finally be the piece that enables me to close my intelligence gap and finally build this thing...