[PD] Advice on distributing pd-based software for apple

Josh Moore kh405.7h30ry at gmail.com
Sat Sep 19 10:36:15 CEST 2020


>
> <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 <kh405.7h30ry at gmail.com>
>> 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 <jmmmpais at gmail.com> 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
>>>> _______________________________________________
>>>> Pd-list at lists.iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> https://lists.puredata.info/listinfo/pd-list
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200919/d1b75fa7/attachment.html>


More information about the Pd-list mailing list