>Coleman died homeless and destitute in 2006. It was unlikely he was aware of the impact he had made on music. Neither he [band leader Spencer] nor Coleman received royalties for the break.
"Samples" were kind of like musical memes in the 1980s. What made for a good sample had a lot more to do with convenience and luck. The sounds that were picked for drum samples had more to do with how useful they were - the dynamic range, how isolated the drums are, how easy they were to mix.
The other famous drum sample - the "Funky Drummer" as drummed by Clyde Stubblefield for James Brown, Stubblefield didn't think the particular drum pattern he used was particularly noteworthy. In that case, James Brown's production choices were actually more key - his signature sound revolved around really crisp drums that he insisted needed to be clear on AM Radio and Jukeboxes. Which is what made it so useful for sampling.
Maybe, but the amen break has a very specific je ne sais quoi that makes it way more useful and pleasant as a sample than almost any other sample. There's just so many situations in the kind of music I make where the amen is like the only loop that fits. Funky drummer might come in second.
It could just be its cultural weight has me hypnotized. But maybe its just that good
I’ve produced music through much of 2010-2020, I wasn’t there in the 1980-2010s but it wasn’t uncommon see discussion online about different samples or things like this. Never really seen any mention something like this unquantified “je ne sais quoi” or at least don’t really recall
My take is, it was the first of its kind to widely circulate exhibiting desirable quantities for sampling, a combination of good enough and path dependency. After a certain level of saturation/entrenchment it carried an aesthetic compared to readily available samples (maybe this is what you meant).
Whenever I couldn’t find a breakbeat sample (or wanted some starting point at least) I’d default to it. When I did music production it was very easy to get your hands on a loop but obviously that’s much later.
I mean, look at any house or hip-hop track, sampling's like the most fundamental part of both genres.
The track you've mentioned is the prime example of the blend of those two genres. Before the term Eurodance caught on, this track would be referred to as hip-house (as in hip-hop + house). Chicago and the broader NY area did it first, but it was a Belgian track that first topped the US charts (Technotronic's Pump Up The Jam).
That's why one of the super simple improvements I'd make to music copyright law, if I had to choose one thing rather than a massive overhaul, is for sampling to also be subject to the compulsory mechanical royalty system.
So any artist could sample something, do some paperwork, and send of a fraction of royalties. Rather than the current system where you need explicit permission from the recording artist and have no recourse if they say no.
So many music genres exist because of sampling, and the shit legal precedents set in recent decades ruined an amazing thing.
Completely agree with you, but good music always finds its way around copyright, you just can't find it on streaming services.
For example, if the sample's small enough to not be recognisable by algorithms, they often end up on Soundcloud with a free download via Hypeddit. Some even get away with charging money for their track with non-cleared samples via Bandcamp. Because those types of bedroom producers are almost always clueless about copyright, they often cite fair use in the description and choose a Creative Commons licence, which is not how anything works. Even some B-list celebrities that damn well know what they're doing still decide to do that when they fail to clear a sample. Soundcloud would be completely irrelevant if they did a good-enough job at enforcing copyright, so they do the bare minimum labels require of them to keep running, but that definitely kills their odds of ever competing with the likes of Spotify.
Then there's a whole "gray area" of online record pools where the audio preview and download links are hidden behind a $25/month or so paywall, so record labels can't scan it directly to even know about the infringement. Usually just listing the names of available tracks in HTML is enough to get them de-indexed from Google, but they rely on word-of-mouth anyway.
And, of course, even if all of that were to stop, you can never prevent a bunch of DJs and producers DMing each other tracks, hottest of which always end up getting shared too widely at some point and uploaded to Soulseek or something.
Meanwhile, streaming services are being flooded by unethically-trained, AI-generated music, which is actually incredibly easy to detect if streaming services actually gave enough of a fuck to do so. There is one that gives a fuck rather publicly (Deezer) and according to them, it's ~34% of everything uploaded as of a few months ago, may have passed 40% as of now.
I’ve heard conflicting accounts about their knowledge and royalties.
While I’m certain they didn’t receive royalties from all artists, I heard many 80s artists did. And Amen Brothers took others to court. So they would have know about the use of the break.
I will admit I haven’t done any independent research into this matter personally. Just echoing accounts I’ve read and taking their reports at face value.
I just got the name of the band muddled with the name of the song. I also sometimes get get the names of my friends and loved ones muddled. But that doesn’t mean I don’t know them either. I’m just shit with names.
I do however remember every useless number I learned as a child. Including phone numbers to kids TV shows. Human memory is weird :-/
A reminder that your society will be judged not on how the most fortunate lived but how the least fortunate lived. Context still matters but there's a meaningful difference between "Anne Brontë died of Consumption (Tuberculosis), at that time there was no cure" and "Dave died of TB, he couldn't afford the cure at current market prices".
Unless you are one of the rare unintegrated humans†, in which case you wouldn't read HN because you don't have any of the necessary technology, there is only a single human society. Given that, we should be uncomfortable about how we're doing on that "least fortunate" thing...
What is a mote in such a society to do though? Dave couldn't afford the cure, but neither can I. What do you suggest I do to make it affordable for both of us?
This is our manifesto. We are creative people. Here is our strategy for advancing creative work and supporting the people who do it.
We upvote comments that completely miss the point of how this algorithm works. We upvote comments that claim the algorithm does nothing at all. We downvote comments about how the creator of the original drum break died destitute.
I'm so excited about this! And I expect the speed/bandwidth improvements in the new renderer to be very significant.
I spent a while hacking on my own fork of the Bubbletea renderer over the last few months in order to run a game over SSH[1]. It was a ton of work for a niche, simple game (snake) but it dropped bandwidth usage by a factor of 10. The new renderer has to be more general so it might not quite hit that for all applications, but I bet it's not that far off.
I could also see it being an even more significant gain for apps that use a lot of modern colors and styling, since escape sequences there can be very long / heavy weight.
Some of the comments here are annoyed about the website branding but FWIW I think bubbletea and lipgloss (and wish, if you want SSH stuff) are really excellent tools for building "boring" TUIs too.
at my last job code review was done directly in your editor (with tooling to show you diffs as well).
What this meant was that instead of leaving nitpicky comments, people would just change things that were nitpicky but clear improvements. They'd only leave comments (which blocked release) for stuff that was interesting enough to discuss.
This was typically a big shock for new hires who were used to the "comment for every nitpick" system; I think it can feel insulting when someone changes your feature. But I quickly came to love it and can't imagine doing code review any other way now. It's so much faster!
I'm not sure how to tie this to AI code review tbh. Right now I don't think I'd trust a model's taste for when to change things and when to leave a comment. But maybe that'll change. I agree that if you automated away my taste for code it'd put me in a weird spot!
This is the workflow I've always dreamed of. In a lot of ways making a change which is then submitted as patch to their patch isn't really that different from submitting a comment to their patch. The workflow of doing that directly in editor is just wonderful.
If I had to pick, I actually think ONLY being able to submit "counter-patches" would be better than only being able to submit comments. Comments could just be actual programming language style comments submitted as code changes.
Typically in this system you encode obligations - e.g. "eieio should review, or at least be aware of, all changes made to this library." I think that means you're unlikely in practice to have a problem like that, which (unless the team is not functioning well) requires two people who care deeply about the variable name and don't know that someone else is changing it.
If minor mistakes are corrected without the PR author's input, do they ever learn to stop making those mistakes themselves? It seems like a system where you just never bother to learn, e.g., style conventions, because reviewers just apply edits as needed.
> What this meant was that instead of leaving nitpicky comments, people would just change things that were nitpicky but clear improvements. They'd only leave comments (which blocked release) for stuff that was interesting enough to discuss.
This is my dream; have only had a team with little enough ego to actually achieve it once for an unfortunately short period of time. If it's something that there's a 99% chance the other person is going to say 'oh yeah, duh' or 'sure, whatever' then it's just wasting both of your time to not just do it.
That said, I've had people get upset over merging their changes for them after a LGTM approval when I also find letting it sit to be a meaningless waste of time.
Interesting approach. I think it could have the reviewers to be more serious about their feedback. Comments are a bit too casual and may contain more "unconstructive" information.
The tool (iron) isn't open source, but there are a bunch of public talks and blogs about how it works, many of which are linked from the github repo[1].
It used to be "open source" in that some of the code was available, but afaik it wasn't ever possible to actually run it externally because of how tightly it integrated with other internal systems.
If I understood correctly, the same can be done on VS Code with the github plugins (for github PRs)
It's pretty straightforward: you checkout a PR, move around, and either make some edits (that you can commit and push to the feature branch) or add comments.
Yeah, it's called git: make your own branch from the PR branch, commit and push the nitpick change, tell the author, and they can cherry-pick it if they approve.
Gitlab has this functionality right in the web UI. Reviewers can suggest changes, and if the PR author approves, a commit is created with the suggested change. One issue with this flow it that's it doesn't run any tests on the change before it's actually in the PR branch, so... Really best for typos and other tiny changes.
Alternatively you actually, you know, _collaborate_ with the PR author, work it out, run tests locally and/or on another pushed branch, and someone then pushes a change directly to the PR.
The complaints about nitpicks slowing things down too much or breaking things sound like solo-hero devs who assume their god-like PRs should be effectively auto-approved because how could their code even contain problems... No wonder they love working with "Dr Flattery the Always Wrong Bot".
I think you misunderstood the tooling I was asking about. This is what was mentioned:
> at my last job code review was done directly in your editor (with tooling to show you diffs as well).
That's not covered by git itself. And it's not covered by Gitlab, GitHub, or any other web-based forge.
> Alternatively you actually, you know, _collaborate_ with the PR author, work it out, run tests locally and/or on another pushed branch, and someone then pushes a change directly to the PR.
Of course you should collaborate with the author. This tooling is a specific means to do that. You yourself are of course free to not like such tooling for whatever reason.
> The complaints about nitpicks slowing things down too much or breaking things sound like solo-hero devs who assume their god-like PRs should be effectively auto-approved because how could their code even contain problems... No wonder they love working with "Dr Flattery the Always Wrong Bot".
Did you maybe respond to the wrong person? I'm not sure how that relates to my comment at all.
* Yes, I clearly know what tcpdump is / how to capture network traffic
* It has been several years since I have looked at a pcap
* I don't have wireshark installed on this computer
* I've done the thing where you decrypt TLS with wireshark exactly once, years ago, and I found it frustrating for reasons I can't remember[1]. Wasn't sure if I could do this with ssh
* When I started investigating this, I didn't remotely think that ssh was the root cause. I thought it was a quirk of my game
* I *did* make a client that printed out all the data it was receiving, but it was useless because it was operating at the wrong layer (e.g. it connected over SSH and logged the bytes SSH handed it)
* I'm experimenting with Claude Code a lot because it has a lot of hype and I would like to form an opinion
* Looking up flags is annoying
* Being able to tell an agent "look at this pcap and tell me what you see" is *cool*
So idk. I'm sure that you would have solved this much more quickly than I did! I'm not sure that (for me) opening up the packet in Wireshark would have solved this faster. Maybe reading the SSH spec would have, but debugging also just didn't take that long.
And the big leap here was realizing that this was my SSH client and not a quirk of my game. The time at which I would have read the SSH spec was after I captured traffic from a regular SSH session and observed the same pattern; before that I was thinking about the problem wrong.
I don't think that this is unfortunate. In fact, I think I got what I wanted here (a better sense of Claude Code's strengths and weaknesses). You're right that an alternative approach would have taught me different things, and that's a worthy goal too.
[1] I suspect this is because I was doing it for an old job and I had to figure out how to run some application with keys I controlled? It would have been easier here. I don't remember.
Thanks for taking the time to respond, and apologies for the contentiousness. I'm a jaded old man suffering from severe LLM fatigue, so I may have come off a bit harsh. Your write-up was a good read, and while I might be critical of your methodology, what you did clearly worked, and that's what matters in the end. Best of luck with your project, especially the go lib fork.
> Or you could use anycasting to terminate SSH sessions on the moral equivalent of one of a number of geography based reverse proxies and then forward the packet over an internal network to the app server over a link tuned for low latency.
I've been thinking about some stuff like this! Not being able to put my game behind Cloudflare[1] is a bummer. Substantial architectural overhead though.
> The idea of letting Claude loose on my crypto[graphy] implementation is about the most frightening thing I've heard of in a while [though libnss is so craptastic, I can't see how it would hurt in that case.]
I hear you, but FWIW the patch I was reverting was trivial (and it's also in the go crypto library, which is pretty easy to read). It's a couple-of-line change[2], and Claude did almost exactly what I would have done (I was tired and would have forgotten to shrink the handshake payload).
[1] This isn't strictly true, Cloudflare spectrum exists, but its pricing is an insane $1/GB last I checked.
Nice, but shouldn't the behaviour change be behind a config setting? And it's not clear what the intent of the change is. Implementing PING/PONG seems different from what you said you were trying to do. And it's section 1.8 of the OpenSSH [PROTOCOL] reference, not section 1.9.
But... before you think I'm trying to be negative... good on you. I wish you well. Getting crypto/security code into open source projects can be a slog as people frequently come out of the woodwork, so don't get discouraged.
And the more I think about this... there's plenty of examples out there about doing HTTP based reverse proxying, but essentially zero for SSH proxying, so if you do that, it would make a great blog post.
And of course it totally doesn't work if the client doesn't have JavaScript at all. I read the HN front-page through an AI summary and it also got censored when it scraped the article.
Yes! While this post was written entirely by me, I wouldn't be surprised if I had "smoking gun" ready to go because I spent so much time debugging with Claude last night.
Serious question though, since AI seems to be so all capable and intelligent. Why wouldn't it be able to tell you the exact reason that I could tell you just by reading the title of this post on HN? It is failing even at the one thing it could probably do decently, is being a search engine.
Oh wow - I've never heard of TCP_CORK before. Without disabling pings I'd still pay the cost of receiving way more packets, but maybe that'd be tolerable if I didn't have to send so many pongs. This is super handy; excited to play around with it.
I am aware of TCP_NODELAY (funny enough I recently posted about TCP_NODELAY to HN[1] when I was thinking about it for the same game that I wrote about here). But I think the latency hit from disabling it just doesn't work for me.
I missed that thread originally, the post and the comments where a good read, thank you for sharing.
I got a kick out of this comment [0]. "BenjiWiebe" made a comment about the SSH packets you stumbled across in that thread. Obviously making the connection between what you were seeing in your game and this random off-hand comment would be insane (if you had seen the comment at all), but I got a smile out of it.
reply