hey, author here. it's been about nine weeks since our last update and that's because we've
been busy building a system where people can make their own sounds and share them with
everyone else.
we thought it would be a good idea because unlike Petty, i just like to play but can't really
produce. he's obsessed with the music side and likes to produce what he plays, so he ends up
with these setups that sound brilliant and until now there was no way to get one of them onto
my phone. now you save what you built as a pack, post it, and anybody can load it and play
with your band.
most of those nine weeks went on making a pack mean the same thing twice, which turned out to
be much harder than the file format. at one point he lost one of his own recordings to a pack
that had no scratch part in it, which is in the writeup.
hope you enjoy it as much as i do. might be an easy way in for anyone who just wants to open
the app and play.
Author here. It's a browser game, but really it's an argument about one security idea that I wanted people to be able to poke at instead of take my word for.
hello sasha here, another post on DrumMate development. gotta good
interaction last time from people so decided to post a new post regarding
how im dealing with toms since i added a feature for it
DrumMate is an accompaniment app, it plays a band that follows the drummer,
no ai the only intelligence is the drummer itself
mic is hard because we're trying to make hardware easy for users so using
the phone which is not a great mic and it gives the whole kit in one signal
kick snare hat was easy cause they sit in different parts of the freq
spectrum. toms are harder because they sit in the snare band
ive only tested it on drums i synthesised and never a real kit. im
wondering if anyone has done a single-mic drum classification and got it
right?
Author here. This came out of building an Android app where a generated
band follows a live e-drummer over USB MIDI, but the writeup is the
platform-agnostic part: why raw hits can't clock anything, why clock
division is causal but multiplication forces you to carry a tempo model,
and the "coasting" behavior that turned out to be the difference between
a follower that works in tests and one that works with an actual drummer.
Happy to answer anything about the tracker internals - onset weighting,
downbeat inference from accent patterns, or why the band schedules
against the clock's forecast instead of reacting to hits (keeps audio
latency out of the drummer's timing loop entirely).
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
I work at a small security startup on a project im pretty passionate about.
We are building open source tools to reduce how much sensitive stuff and power apps keep in one place.
One project is TideCloak, a Keycloak fork that keeps the familiar dx but changes the security model underneath: https://tide.org/tidecloak
Another is KeyleSSH, a keyless SSH/PAM prototype where there is no private key file sitting around as one thing to steal: https://github.com/sashyo/keylessh
Most of what I'm thinking about now is dx. Security tools dont matter much if normal devs cant understand, debug, or actually want to use them.
we thought it would be a good idea because unlike Petty, i just like to play but can't really produce. he's obsessed with the music side and likes to produce what he plays, so he ends up with these setups that sound brilliant and until now there was no way to get one of them onto my phone. now you save what you built as a pack, post it, and anybody can load it and play with your band.
most of those nine weeks went on making a pack mean the same thing twice, which turned out to be much harder than the file format. at one point he lost one of his own recordings to a pack that had no scratch part in it, which is in the writeup.
hope you enjoy it as much as i do. might be an easy way in for anyone who just wants to open the app and play.
happy to answer anything.