In the SP-Tools devices I was pretty brutal with it and manually put the fluid.libmanipulation everywhere. This is before @weefuzzy told me about his approach, that I hope he doesn’t mind me requoting here:
In the top level directory of my project I have a file called openactions.txt that then has these lines in there – it’s the same content as the fluid.libmanipulation-init.txt you’ll find in the init folder of the flucoma package. See attached screenshot.
The list is in the init folder… adding stuff (in the right order) is part of the (awful) m4l machinery in openactions.txt
The contents of this file is:
;max objectfile fluid.dataset~ fluid.libmanipulation
;max objectfile fluid.labelset~ fluid.libmanipulation
;max objectfile fluid.kdtree~ fluid.libmanipulation
;max objectfile fluid.kmeans~ fluid.libmanipulation
;max objectfile fluid.knnclassifier~ fluid.libmanipulation
;max objectfile fluid.knnregressor~ fluid.libmanipulation
;max objectfile fluid.normalize~ fluid.libmanipulation
;max objectfile fluid.standardize~ fluid.libmanipulation
;max objectfile fluid.robustscale~ fluid.libmanipulation
;max objectfile fluid.pca~ fluid.libmanipulation
;max objectfile fluid.mds~ fluid.libmanipulation
;max objectfile fluid.umap~ fluid.libmanipulation
;max objectfile fluid.datasetquery~ fluid.libmanipulation
;max objectfile fluid.mlpregressor~ fluid.libmanipulation
;max objectfile fluid.mlpclassifier~ fluid.libmanipulation
Now, it could be that the package container isn’t properly including the files. Packages are still a voodoo/mystery to me, in terms of what you are actually meant to do, but when the files are properly included they should look like this:
As in, not italicized, and if you right-click, it will show these options (though probably shouldn’t say Copy to Project Folder(?).
Did you manually Consolidate the M4L device? Do you have Always Localize Project Items ticked?
As mentioned above, I still find Packages/Projects super confusing, and just do things over and over hoping that it works properly…
3 Likes
OMG, your answer could not have been more timely! Exactly the info I was looking for… I was in the middle of snooping in your devices… :-))))) THANKS!!!
1 Like
We could perhaps make this better and more automatic. Allegedly, if you give an object a "fileusage" method and register it, Max will call it at freeze time, and thus all the dependencies will be frozen into the device inclusive of whatever you define. I did some cursory work on this here:
I could pick it up someday, but I just don’t have the time right now.
3 Likes
Great thank you! I was missing the steps on manually consolidating and having always localize project items ticked.
I don’t have another machine to test on to hand right now so I can’t say for 100% that I have it all working correctly but I’m hopeful!
1 Like
@james and @DominicThibault do you have access to a Windows machine without flucoma so we can test the device that follows the careful instructions @MattS6464 is devising?
maybe we should put the said instructions here so people could comment on them…
1 Like
I do have access to a Windows machine that I’ll be testing the M4L device on.
However, I’m stuck in the process of exporting a M4L device, even on MacOS. Somehow, whenever I consolidate my externals in the Max project, it keeps crashing and then the project is corrupted. 
D
1 Like
@MattS6464 will reply soon 
I sent you in private the latest frozen version to test in the meantime. If that works, then we have a recipe we will share.
Here’s a draft of the instructions I’ve written for preparing a Max for Live device for distribution.
FluCoMa Max for Live Distribution Tutorial.zip (511.7 KB)
It’s currently just on a pdf with not the nicest layout but if anyone has any comments let me know!
1 Like
It seems @DominicThibault had issues to make it work on Windows - I sent him the one you submitted.
@rodrigo.constanzo can you please do me a favour, and read the instructions and see what is missing (that is, if you frozen devices work on Windows Live)
@jamesbradbury anything we do wrong?
1 Like
That looks good.
I don’t know what triggers something being moved into the project folder and whether it shows up as italics or not, but I find myself having to manually right-click objects to add them sometimes even if I’ve Consolidated already.
Perhaps @weefuzzy knows and/or I would take his word over mine as he uses M4L devices in performance whereas I don’t.
I’m a bit hit and hope too. By and large consolidate just works for simple cases, but might be dicey for things like poly~ subpatchers, js files etc etc. It’s definitely given me plenty of grief in the past.
I think the internals probably quite sensibly have to be a bit cautious to avoid overwriting different versions of files that might be particular to a project but also present in the global search path (e.g. I have a custom build of fluid.libmanipulation for something, and I’m very grateful that Max doesn’t simply zap this if I re-freeze).
Of course, the sticky thing for our purposes is that we’ve bundled a bunch of externals together, but hopefully @jamesbradbury’s thing with fileusage can make that work properly.
1 Like
I can assure you that I am totally confused by many aspects of freezing still. I have a CLI tool that does it for me, but I cannot share it unfortunately. Maybe one day if the other people involved permit it
We can make things vastly better with fileusage calls though. @rodrigo.constanzo the stuff about italics and consolidation and all that are very confusing to me, and often end up doin things I do not expect. As a result my workflow for freezing often looks like this.
- Create AMXD (which is just a project)
- Add specific files I want to work with and ensure that files are outside the max search path
- Freeze device
- Copy frozen version elsewhere
- Unfreeze
- Delete corresponding folder that is created in the Max for Live Projects folder in the Max folder.
You can also avoid a lot of woe by using the relative development path, and turning off all automatic maintenance. This is my happy path at least for now, though admittedly im doing much less these days than I was previously.
Yup, that seems about right lol.
Even when doing stuff like that I feel like it tends to latch onto other versions of files in the search path sometimes, creating loads of headache tracking things down.
Ok! Here’s my report as clearly layed out as possible.
First, I have to mention that we’ve been developing Mosaïque outside of a Max project for code sharing purposes between different devices. So, the first step for us is to copy the content of our AMXD file to a .maxpat file. Then I create the Max project and manually add the newly created .maxpat file. The project then recognizes all dependencies. I consolidate the project using the “Consolidate” function. I manually add [fluid.libmanipulation] to the root folder of my Max project. I create my openactions.txt file. And finally I export
I’ve tried checking the “Include Packages When Freezing” option, but it creates duplicates when I later thaw my device.
So, it seems that, in order to work, [fluid.libmanipulation] has to be in the root folder of your Max project before exporting the Max for Live device. Otherwise, the actions triggered by the openaction.txt file doesn’t seem to resolve the paths properly. Oh! And careful because when you reload the project, [fluid.libmanipulation] gets moved to the external folder, and then freezing doesn’t work!
Also, in addition to @rodrigo.constanzo lines, I’ve added those lines to the openaction.txt file in order to properly invoke [fluid.waveform~] and [fluid.plotter].
;max definesubstitution fluid.plotter jsui @filename fluid.plotter @border 0;
;max objectfile fluid.plotter fluid.plotter;
;max definesubstitution fluid.waveform~ jsui @filename fluid.waveform~;
;max objectfile fluid.waveform~ fluid.waveform~;
That’s about it! Now on to checking cross-platform compatibility! Yay!
1 Like
Interesting.
I have found that opening/unfreezing M4L devices in Max creates redundant folders of everything in your Max documents directory, which can be annoying as it seems to sometimes complain about files being in there when they are duplicates. Plus it can build up very quickly if you don’t manually clear it out every once in a while.
I personally never had the discipline for doing this, but I know a friend (is Pete not on here?) who is a big believer of working only in/on the amxd file directly. So you just build the patch in there, then only edit/manage it, without ever going back into a maxpat. For most of my stuff I end up managing a maxpat enough to get it to a project state, then dump out amxds as needed.
I guess part of the benefit of that is you have to deal with the back-and-forth stuff less once you’ve set it up properly?
