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.
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’.
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.
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
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.
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 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:
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 For now, it kinda works if you delete those externals inside the mxt folder with administrative permissions.
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 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.
@rodrigo.constanzo I’m hoping you can offer some advice. I’m writing a tutorial for the FluCoMa learn website about creating M4L devices that use the data analysis objects within fluid.libmanipulation so that they open correctly without errors on other machines. I’m working on creating an M4L version of the Corpus Explorer tutorial but I can’t get it to work. I’ve had a meeting with @tremblap and he said that you’ve managed to get it working previously.
I’ve edited the openactions.txt file from Max’s project manager in the live device to say: ;max objectfile fluid.dataset~ fluid.libmanipulation fluid.dataset~ ;max objectfile fluid.labelset~ fluid.libmanipulation fluid.labelset~
e.c.t. for each of the data analysis objects.
When placing the frozen device in the Max Instruments folder on another machine, it doesn’t work. Upon opening max using the button on the device, the console returns the error kd.tree~: No such object.
Do you have any ideas for a solution to this issue or any ideas as to why it is happening? Thanks!
