M4L Device - Freezing Mac & Windows Externals

Hello everyone,

I am currently working on a Max4Live device that uses the live descriptors from the toolbox. I don’t have a problem with the library itself, but with sharing the device so that it works on both Windows and Mac.

I work on Windows, and freezing the device and sharing it with other Windows users works fine. However, if someone on macOS uses it, the externals get quarantined. So I borrowed a Mac (running Mojave, fwiw) and recompiled the device. However, another user (which doesn’t use Mojave) got an error saying that the embedded externals are not compatible with his architecture.

Since I know very little about the Macintosh, I was wondering if I should create a device for each macOS architecture, in addition to a Windows version?

This seems a bit cumbersome, so I think I’m missing something.

Thanks in advance,


I’m not a user of M4L so I don’t know how, but I know we are signing our externals so that should not be an issue, and that @rodrigo.constanzo and @jamesbradbury and others have distributed devices publicly successfully. Maybe there is a cheat sheet somewhere?

I’ve distributed quite a few M4L externals with them in and not heard back any issues. It’s possible that all the people will have already done the quarantine thing due to having Max installed, or using other external-dependent M4L devices, so other than offering some instructions on how to upgrade the internal Max to 8.3 (which I think Live already does automatically), I just distribute the M4L devices ‘as is’.

1 Like

Hey @jpjpjp I feel like that what you are explaining is odd, as the externals are signed and should behave as you want them too even if they get frozen in a device. I’m going to try and recreate the problem and see if it happens. I have a few machines here I can test on.

This may be unrelated to their operating system and will emerge if they are using an old laptop though I feel like we actually turned AVX512 off by default so that more machines could run FluCoMa by default. Will have to dig somewhat deeper.

1 Like

Thanks everyone, I understand it’s odd.

Here is a really simple example frozen device (rename the .txt to .amxd)
deviceDebug.txt (3.1 MB)

I made it and froze it on Windows. I tried to share it to a Mac user, this time it wasn’t quarantined but it says that the device contains externals that are not compatible with his architecture.


FWIW I just enabled you to upload .amxd and .maxproj so you don’t have to do workarounds anymore :stuck_out_tongue:

I think maybe the clue here is in the warning not the error. When you freeze a device Max zips up the contents… will ask someone on the inside why this happens and what might be going wrong.

Can you try this and see if its busted for you?

flucoma-test.amxd (2.7 MB)

@jamesbradbury thanks for the .amxd upload :slight_smile:

Your device works on Windows, but have you tried it on MacOS? What architecture did you freeze it with?

I used the 1.0.5 packag from the package manager and froze it with those externals. They are universal binaries so should work for both ARM and Intel.

Which version of the package do you have on your system @jpjpjp and which OS and architecture are you creating the Max for Live device from?

I’m using Windows 11 x64 and Max 8.5.3, and I tried to freeze the device with the pre-release (1.0.6), and also the 1.0.5 from the package manager. I open the device from Ableton with the full MaxMSP version to be able to freeze it. Same errors in both cases

I wonder if this is a Windows 11 issue, possibly.

I did the same steps as you described and produced the .amxd above. I’ll have to find someone else with windows 11 to try.

I just tried freezing it with Windows 10, but I still have the same issue when using on MacOS
deviceDebug - 1.0.5 - Win10.amxd (3.1 MB)

I am able to reproduce this. It happens when you freeze the device from Windows and try to open it on Mac but not the other way around. It’s a problem perhaps with Max for Live and how bundling works or something we need to do. I’ll investigate further and get back to you.


So after some preliminary investigating it seems that it is something to do with how arm64 unpacks the externals from the collective inside the .amxd. If you look inside the internals of the Max application you will find a folder at a similar location here:

/Users/jby/Library/Application Support/Cycling '74/Max 8/Settings/temp64-live/mxt

If you look inside there you will find the externals. If you try and delete them manually with rm -rf it will throw a permission error.

So it’s decidedly not a FluCoMa error but you’ve actually caught a pretty gnarly bug that no-one else has seemed to report. Nonetheless, don’t make a ticket – someone at c74 is already aware and looking into it further :slight_smile: For now, it kinda works if you delete those externals inside the mxt folder with administrative permissions.


Also, which version of macOS are you using to open the device?

Thanks a lot for for investigating this and contacting Cycling!

So far I’ve worked around the problem by recreating the device directly on Mac as you said, but next time I’ll try to have those externals deleted. I froze it on a macOS Monterey v12.6.1 (Intel Core), and it seems to work everywhere now.

I hope Cycling will find a solution to this soon :slight_smile:

I don’t know if it’s relevant or related but I had the same problem. freezing on
Win10 and then all the zlib warnings on Mac. But as a first measure I updated Max + Live and tried to freeze again and that already solved the problem for me.


I tried to update everything, but unfortunately it doesn’t seem to work any better atm