Yes, a shame. I honestly expected this could get picked up as a mainstream news story over Christmas (except I think the actual story is older than this video);
Young people with talent and ingenuity, using modern skills and tools to acquire and maintain something with a history behind it.
I've bookmarked it for next time some old guy complains that young people aren't smart or motivated etc. etc.!
Acquiring one of these "ScratchAmp" boxes that was missing its software is what started the whole project. These earlier systems deserve a lot of credit. If I'd had access to the software I don't imagine I would have dug so deeply into the concept.
The records used by xwax have about 100 kilobytes of data on each side of a 12" record. However, the goals are very different here; it's designed to decode the position under specific conditions such as being moved very fast, in reverse and changing direction rapidly. There would be a more efficient encoding if your goal was to fit as much data as possible and relax the other requirements.
How do you propose that you'd select and load tracks? Or view time remaining. Even if you don't care about a waveform display, some sort of computer (ie. display) seems to become necessary at some point. Perhaps you could check the PiDeck project, which puts xwax into smaller hardware.
xwax /is/ meant for end-users, but right at the beginning it only had actual live professional use in mind. I was literally DJ'ing in clubs at the time and I wanted the digital equivalent of playing vinyl records.
I was collaborating with a friend on the early versions, to see if it could be commercialised to provide a "house" system for radio studios and clubs (much like the house provides CDJs or turntables). Today that's superseded by DJs bringing their own laptops, of course.
I don't know much about Mixxx these days; that project was always much better set up to grow through a range of contributors (eg. with its scripting engine). But I think it's technical architecture is probably quite different.
Whereas, xwax was designed from day 1 with the idea it was a realtime system with very tight latencies, taking input from one audio interface and responding to it on another. That was fun on Linux (and FreeBSD!) systems of the early 2000s.
xwax author here, nice to see it submitted to HN front page. Must be 20+ years now since I wrote the original code for DJ'ing live. Very happy to answer questions
Fair, I was thinking that because its not actually an X11 GUI (though it is X11 of course)
Its fun to query or set information on a remote. The same applies to xdpyinfo, xset, xrandr and many more support the -display option (if they don't then set the DISPLAY environment variable).
It's a reasonable hurdle; an employee who previously signed an NDA (or any one, for that matter) needs to be able to design new systems without regurgitating verbatim parts of an old one under NDA.
So it's really not a big ask to navigate their own NDA and come up with something interesting to talk about at an interview.
Don't these results show a 20% slower based on the median?
Plus, the test uses a display at 120Hz, which is a substantial head start -- by making each frame of delay half as long compared to us mere mortals running at 60Hz.
Isn't there an 'arrogance' in the premise when we ask these sorts of questions? Not a personal criticism; just an aside from the technical question for a moment.
It's the assumption that we've decided something we created should have permanence.
Similar to billionaires deciding they would like to live forever and trying to make it happen.
There's a beauty to the world, which is we get a short time to contribute, and then we give up our space/resources to make room for someone else. Our ancestors decide whether and what to carry forward.
Yes, I feel Stripe has lost its edge with the new APIs. Interesting to hear 'demotivating' used as that's how I felt for a while. I needed many requests with Stripe support and could see the docs changing each time I returned to the task.
The interesting one for me is the way the client triggers the transaction, and the server has to asynchronously process that. I'm pretty sure I'm still having dreams at night about all the edge cases and whether I've truly covered them. Others are probably a more "that seems to work" style of development.
I was really happy with my idempotent IDs before....
Young people with talent and ingenuity, using modern skills and tools to acquire and maintain something with a history behind it.
I've bookmarked it for next time some old guy complains that young people aren't smart or motivated etc. etc.!