psobot

Are the ROMs, though? (Not trying to be combative; I've had to deal with this a lot when developing emulation-based plugins.)

Nice work! I had the same fun RE adventure in https://github.com/psobot/keynote-parser a couple years back, based on Sean Patrick O'Brien's work back in 2013: https://github.com/obriensp/iWorkFileFormat/blob/master/Docs...

Exactly that, yes! IR receivers outside every exterior door to the building, and IR receivers in the elevators to control access on a floor-by-floor basis.

The fobs were visible by an IR camera (including the average smartphone) and could trivially be decoded as a short bit sequence with an IR sensor wired into a microphone jack, as the bit pattern was transmitted at ~audio rates.

Viscount has hilariously bad security. I used to live in a building in Toronto that used Viscount infrared fobs for access control. They were no more secure than TV remotes; no rolling codes, no encryption, nothing. An attacker could easily sit nearby with an IR receiver and collect everyone's fob codes at a distance, allowing access to all floors.

Needless to say, I moved.

Assuming what you've written is accurate:

The first and best solution is to help these people improve, obviously. You've tried that, but it's not working quickly enough. (People can always be coached; some are just more coachable than others. When I hear that someone "isn't learning," that always reads to me as someone who's "learning more slowly than I have patience for.")

Then, the second-best solution is for management to move people around to other teams, or out of the company. Unfortunately, that's difficult and slow - and sometimes impossible, depending on the company culture or regulations.

Then, the third-best solution: move yourself to an environment with "better" people in it. This also may not be possible or desirable; job changes are difficult and can be risky.

So, the fourth-best (but most common) solution: make your peace with the situation by finding ways to become comfortable with the gap between your expectations of your colleagues and their actual performance.

Some strategies:

- Remind yourself that "the company pays me well to put up with this." (And if the company doesn't pay you well enough to make it worth it, then yes, absolutely leave. I assume Microsoft pays you well though.)

- Dig deep to find out what frustrates you about working with these people, and address those concerns instead. Are you frustrated because these people increase your workload? Are you worried that their lack of quality work will reflect poorly on you? Do you worry that they will compromise work that you care about? These are all insecurities that can be addressed.

- Remember that intelligence is not linear; nobody is strictly smarter than somebody else in every aspect of life. These people may be good at parts of their jobs that you don't see, in which case your expectations of these people may be what needs to change.

Really excited to see this - very nice work Brian et al!

FWIW - you can enable Apple's built-in text message forwarding to proxy those SMSes via your iPhone to your Mac - it's pretty seamless.

See: https://support.apple.com/en-ca/guide/messages/icht8a28bb9a/...

Every post from patio11 is such a joy to read: precise, exact, descriptive, and entertaining. I'd love to understand where his writing style comes from and how to emulate it.

MAME seems to have had "skeleton driver" (i.e.: very rough and unfinished) support for a number of 80s- and 90s-era synths, given that they're very similar to video game hardware from the same era. In my reverse engineering for this project, I realized that the MAME driver might now boot, but there's an extremely long way to go before audio comes out; the K2 series used custom ASICs for waveform generation that have no public documentation. I've heard that some folks much smarter than me know how to de-cap chips and reverse engineer them from the hardware, but I'll be extremely impressed if someone can make that happen and emulate those chips efficiently.

I couldn't think of a better response to a blog post than "I wish I had seen this article sooner." Thank you!

(also posted in response to another comment)

I'll give you a hint - the post was originally twice as long and _did_ go into detail about why I wanted to patch something, but a reviewer of the post pointed out that I could potentially have run afoul of one or more laws in one or more countries if I had succeeded in doing so.

I'll give you a hint - the post was originally twice as long and _did_ go into detail about why I wanted to patch something, but a reviewer of the post pointed out that I could potentially have run afoul of one or more laws in one or more countries if I had succeeded in doing so.

Instruments wouldn't be that hard to add to Pedalboard, but we don't have a use case for them on my team just yet. I might give that a try in the future, or might let someone else in the community contribute that.

Pedalboard doesn't support GUIs at the moment, but there's an issue on GitHub to track that: https://github.com/spotify/pedalboard/issues/8

No Echo Nest code was included in this project specifically, but my team owns a lot of the old Echo Nest systems, data, and audio magic (i.e.: what used to be the Remix API, audio features, audio analysis, etc.). Pedalboard is being used to continue a lot of the audio intelligence research that started way back with the Echo Nest!

(Fun fact: the Echo Nest's Remix API was what got me interested in writing code way back in high school. Now, more than a decade later, I'm the tech lead for the team that owns what's left of it. I still can't believe that sometimes.)

Pedalboard is a wrapper around the JUCE framework (https://juce.com), which is dual-licensed under the GPLv3 or a custom paid commercial license. We chose to license it with the GPLv3 rather than coming up with a dual-license solution ourselves, given that this is an audio processing tool in Python and will usually be used in scripts, backends, and other scenarios where users of Pedalboard are not likely to distribute their code in the first place.

We use Pedalboard (and Python) for offline/batch processing - mostly ML model training.

Pedalboard would also be usable in situations that are tolerant of high latency and jitter, though, given that all audio gets handed back to Python (which is both garbage collected and has a global interpreter lock) after processing is complete.

There is! Check out http://research.atspotify.com/.

Thanks!

That's correct: Pedalboard just adds effects to audio, but doesn't have any notion of layers (or multiple tracks, etc). It uses the Numpy/Librosa/pysoundfile convention of representing audio as floating-point Numpy arrays.

Mixing two tracks together could be done pretty easily by loading the audio into memory (e.g.: with soundfile.read), adding the signals together (`track_a * 0.5 + track_b * 0.5`), then writing the result back out again.

Adding silence or changing the relative timings of the tracks is a bit more complex, but not by much: the hardest part might be figuring out how long your output file needs to be, then figuring out the offsets to use in each buffer (i.e.: `output[start:end] += gain * track_a[:end - start]`).