> > <https://lists.puredata.info/listinfo/pd-list> >> And more to this point... >> https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-require-signed-code/ >> >> This means that once the transition to Apple Silicon takes place, in the >> future you might not be able to distribute binary form stuff not >> distributed through the App Store and/or signed by a registered developer >> eventually. You will be able to compile source code and run your own >> signatures, but otherwise you're SOL. It's clear from their latest actions >> that even the "allow" button in the control panel is a stop-gap measure. >> Better off just distributing the source code with a shell script and having >> everyone self sign their apps, same amount of terminal commands just a bit >> of waiting. You could theoretically distribute externals that way too by >> calling the shell API from pd itself after it's compiled. Heck you could >> probably do it with deken and tcl alone and not have to worry about >> packaging multi-os packages they'd just have to wait a little longer than >> getting a binary. I've had success getting pd to compile in Windows >> Subsystem for Linux which can run as a terminal right in VS Code it's >> freaking awesome to be honest and as VS Code also has a OSX counterpart (as >> with Linux) it's relatively trivial to just modify the environment, >> generate one big sh file with a case selection for what machine you want to >> target, and you're done. >> >> On Fri, Sep 18, 2020 at 11:00 PM Josh Moore <[email protected]> >> wrote: >> >>> Not sure it's even really worth it. Apple is hostile to open source and >>> multi-platform stuff these days and everyone else who isn't them to be >>> quite honest. >>> >>> They want to control graphics (deprecate opengl, don't support vulkan, >>> force everyone to use their special API completely incompatible with >>> everything else, boot Epic's engine cuz it doesn't want to pay a premium >>> conveniently during their push for Arcade and all of this) >>> >>> They want to control their processors, lock them down, force you to pay >>> a hundred bucks a year to access the latest development tools or distribute >>> applications, and reject anything they don't like or competes with anything >>> they have unless they make more money from you than they make from their >>> own software. >>> >>> All anyone needs to do is fork some RTOS *nix microkernel with decent >>> support for graphics hardware and nobody has a reason to use that stuff >>> anymore unless they want to use Logic. This is basically what Blackmagic >>> did for their new hardware, it's all RTLinux as is a lot of the new digital >>> consoles. But regardless of my gripes with Apple's crappy antics lately >>> these things are really something Miller himself needs to take up with >>> Apple as they do offer free app store access to universities and they might >>> be interested in embedding Pdlib in logic environment to compete with >>> Ableton. We'd have to get externals merged by Miller for this to work out >>> though as since the whole Unreal Engine debacle caused Apple to change >>> their ToS requiring each piece of code/app has to be ran through >>> their approval process or they'll cut you off of xcode/app store/apple id >>> with no recourse. But beyond that it's so much cheaper especially for the >>> students this software is aimed at primarily to just stick pd on a RT >>> patched linux kernel on a 50 dollar ARM SBC and call it good. >>> >>> On Fri, Sep 18, 2020 at 8:53 AM João Pais <[email protected]> wrote: >>> >>>> Hi list, >>>> >>>> I'm preparing a package based on Pd work, but I run into annoying >>>> problems with recent apple OSs, namely notarization and security. Things >>>> seem to work if the user commits to switching off all security protocols, >>>> but for people who don't know Pd, they might be squeamish about this. >>>> Therefore I wanted to ask a couple of questions to someone who might have >>>> experience in distributing pd-based patches. >>>> >>>> For clarity: the package is a max patch (for both runtime and >>>> standalone versions), with the Pd app and patches included in a supporting >>>> folder - running with the recent pd~ object. When done properly, the user >>>> won't even be aware that pd itself is running. >>>> >>>> - how can one avoid asking a user to allow safety access to Pd and its >>>> externals? And while at that, to the max standalone as well? >>>> - I'm myself a windows user, and don't have a mac - I can only get the >>>> standalone compiled when a friend grants me access to his computer. Which >>>> system do you advise to prepare a package? It works fine in 10.13, from >>>> 10.15 seems to be problematic. >>>> - I had a look at codesigning a package, but it seems that it's >>>> necessary to sign up as an apple developer and pay 100us a year, which I'm >>>> not willing to do. The package won't be going to any app store, it's just >>>> to distribute as a zip file for computers. Any way to circumvent this? >>>> >>>> Best, >>>> >>>> jmmmp >>>> _______________________________________________ >>>> [email protected] mailing list >>>> UNSUBSCRIBE and account-management -> >>>> https://lists.puredata.info/listinfo/pd-list >>> >>>
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
