am15 (@am15)

Hey — listen, I spent part of last night poking at PHP MIDI Library (app) under the OrchardKit umbrella, and I figured I’d write this down while it’s still fresh. Not a review, not a how-to, just a “here’s what broke and how I unbroke it” kind of note you’d drop to a coworker on Slack.So the goal was pretty mundane. I wanted to parse and tweak a handful of MIDI files locally on my Mac, generate some variations, and feed them back into a small toolchain. Nothing exotic. The library itself is straightforward PHP, but I was running it inside a small macOS wrapper I use for testing utilities without dropping straight into Terminal every time. macOS Sonoma 14.1, MacBook Pro with an M1 Pro. Clean machine, no weird system mods.What went wrong was subtle in the most macOS way possible.The app launched fine. No Gatekeeper drama. No “developer cannot be verified” warning. The UI came up, PHP runtime initialized, logs looked clean. But every time I tried to load an actual MIDI file, the tool behaved as if the file didn’t exist. No exception. No error output. Just empty results, like I’d passed it an empty directory.My first reaction was predictable: “Okay, I messed up the path.”So I double-checked paths. Absolute paths. Relative paths. I printed them out. I echoed file_exists() results. Everything checked out. PHP itself was clearly running, but as soon as it touched the filesystem outside its own little sandbox, things quietly failed.Second attempt: reinstall everything.I reinstalled the wrapper app, re-downloaded the library, cleared caches, even rebuilt the PHP binary I was using just to rule out something dumb. Same behavior. Still no access to actual files. Still no errors.At this point I briefly suspected the library itself, but that didn’t really make sense. MIDI parsing doesn’t just… stop working silently. And the same scripts worked fine when I ran them directly from Terminal.That contrast was the clue.The moment I ran the same code outside the macOS app container, everything worked. Which meant the problem wasn’t PHP and wasn’t the library. It was macOS being macOS.What I eventually realized is that the wrapper app never got permission to access user files, and macOS never bothered to ask. No prompt. No dialog. Nothing. The system just defaulted to “nope,” and the app politely accepted that decision without complaining.Apple documents this behavior, but mostly from the developer side, not the user side:https://developer.apple.com/documentation/security/app_sandboxOnce I suspected permissions, the fix was almost boring. I went to System Settings → Privacy & Security → Files and Folders. Sure enough, the app wasn’t listed there at all. Not denied. Just missing. Which effectively means zero access.I manually granted it access to my Documents folder, fully quit the app (not just closing the window), and launched it again.Instantly different behavior.The same scripts that returned nothing before now loaded MIDI files correctly. Track data appeared. Parsing worked. Output files were generated exactly where I expected them. No code changes. No library changes. Just permissions.While I was sanity-checking all this, I bookmarked this page because it mirrored what I was seeing and helped confirm I wasn’t chasing a ghost:https://rvfcb.com/developer/17418-php-midi-library.htmlFor reference, if someone wants to see whether there’s an App Store–distributed build involved (sandboxed vs non-sandboxed), Apple’s official search is here:https://apps.apple.com/us/search?term=PHP%20MIDI%20LibraryAnd if you want Apple’s user-facing explanation of why apps sometimes “work but don’t,” this support page is oddly relevant:https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-mchl1bb43b4b/macWhat tripped me up is that nothing felt broken. No crash. No warning. Just missing data. It’s the kind of issue that makes you doubt your own code first, which is exactly what macOS seems to count on.If I were doing this again tomorrow, here’s the short checklist I’d keep in my head:Don’t trust silence. If an app loads but can’t see files, assume permissions first.Check Privacy & Security manually; don’t wait for a prompt that may never appear.Quit and relaunch after changing permissions. macOS won’t hot-reload that state.Test the same code outside the app container to separate OS issues from logic bugs.Anyway, that’s the whole story. Nothing dramatic, but one of those problems that can waste an hour if you don’t recognize the pattern. Once you’ve been burned by silent sandboxing a few times, you start seeing it everywhere.