creating patchers from Max abstractions with JavaScript causes error when Max Editor is closed
Hi there,
I am experiencing a strange behavior (which seems to be buggy - or at least undocumented behavior by design ;-) : creating patchers from Max abstractions with JavaScript in a subpatcher causes an error output to the max console :
"name of the abstraction" : No such object
See the attached Anomaly_fails.amxd.
But the file of the Max abstraction is in the same folder as the M4L device (.amxd) and it was found when the JavaScript was executed after device load & initialized (via live.thisdevice).
Strange thing : same logic in the top level patcher of the M4L device and no error occurs - see the attached Anomaly_works.amxd for this one.
This error is triggered by the live.thisdevice event - but saving the M4L device in the Max editor does also tigger this event in the device that exists on the track in the Live Set, which can be seen by the name the instance prefix of dictionary BUT with no error.
Also a drag & drop of the M4L device on a track causes no error - the code seems to be fine.
So there has to be something strange happening when we edit a M4L patch in the Max editor and closing the Max Editor - but what?
Cheers
Edit : also the docs about the preview mode give no hint : https://docs.cycling74.com/max8/vignettes/live_preview and switching the preview mode button in the Max editor to off creates the same error as closing the editor ... hence its about the "reactivating" of the device instance in the track of the Live set.
Haven't tried this myself, but have you tried explicitly including all the files in your project file (as opposed to just putting them inside the project folder)?
Hi Tyler,
thanks for your hint & reminder, very much appreciated !! … yes, the default „project behavior“ of Live, when you open a Max 4 Live device into the Max Editor, may be the cause.
And for all the others who stumble upon this or some similar strangeness ;-) …
Whether it’s a M4L device listed in the Live browser (stock or 3rd party) or one developed in a folder, Ableton Live (or the embedded Max runtime & helper) automatically creates a project folder under „~/Documents/Max 8/Max for Live Devices“, which in case of a M4L device development „in a project folder (only)“ is just empty.
But the interesting thing becomes visible when one opens the Project Window from the bottom toolbar of the Max editor „Show Containing Project“. This lists all known dependencies and it does contain the *.amxd file and the JavaScript file (which is referenced in the sub-patcher), but it does not list the file of the max abstraction (foo.maxpat) - see the attached screenshot below.
And I guess on the M4L device (re-)instantiation in Live, that happens when the Max Editor is closed, it uses this „default project“ information, which misses the information of the max abstraction file location.
But that’s only one part of the strange story - why does this work, when the JavaScript is located, and the max abstractions will be created, on the top level (and not in a sub-patcher).
And most interestingly : where does Live hold this „default project“ information - its folder can be seen in the file system, but its empty?
In the case of a „project folder based“ Max 4 Live device development, I guess they just scan the *.amxd file (holding this information in RAM and do not store it to disc) and hence we can see the usage of the JavaScript file in a „js“ Object - and that’s it.
This could explain, why the dependency to „foo.maxpat“ is missing, as this file information is hold in the JavaScript file and it matters when the *.amxd file is parsed.
If the parsing happens when the dynamic creation of the patcher (loading in the max abstraction foo.maxpat) by the JavaScript did not take place yet, the use of „foo.maxpat“ cannot be detected.
When "foo.maxpat" was not existant and hence not scanned in the *.amxd, why does an error related to "foo.maxpat" occur? This might be the case when the parsing happens prior to live.thisdevice "left outlet bang", which tiggers the dynamic creation of the max abstraction in the JavaScript ... but this are all guessings and I cannot see a clear picture of what & why it happens ;-).
But Ableton Live (and the Max 4 Live runtime ) got access to the file path of the Max 4 Live device as it was dragged on the track from the development folder.
So in the end it seems to be a „messed up“ lookup strategy of the Max 4 Live runtime : default project folder (created by Live automatically) vs. development folder … which should not happen, I think.
This may be caused by the fact, that a M4L device developed in a folder only, is not a frozen device by default - as the unpack to project folder behavior is normally executed by unfreezing a device (at least to the docs tale ;-).
And this fact might be dropped by the Max 4 Live runtime - it does not recognise that a M4L device developed in a folder, was not frozen before it was dragged onto a track in Live and handles it the same way as a normal distributed & frozen device.
But I will dig deeper into it, also try the Max project approach and report back what I find out.
The official Cycling 74 Docs on Max projects (https://docs.cycling74.com/max8/vignettes/projects_topic), only offer some basic information for Max 4 Live device developments using Max projects (https://docs.cycling74.com/max8/vignettes/projects_devices).
Does anybody know about some tutorial or otherwise assembled information about using Max projects for Max 4 Live device developments, which shed light on the things that are not obvious, but essential and share some background information?
Just a "short" update ... got a first kind of success ... created a bnomaly on the way through the darkness that was created by the lack of proper documentation, but hopefully no black hole ;-)
1) I took the path to create a new Max project, hence completely decoupled from Live in the frist place - thought this was a good idea - and stored the project in a freely chosen place ... maybe not a good idea (see below).
2) Copied all the top level code of the Anomaly_fails.amxd patch into the first created *.maxpat (inside the Max project) and added the Max abstraction and JavaScript files to the project as well.
That in some cases Max creates subfolder for code and patchers and move "existing files" into them and sometime not, is one of funny surprises in the darkness ;-).
3) From the Project Windows bottom toolbar I chose "Export Max for Live Device ..." and saved the resulting *.amxd file in special folder.
And now I got myself 3 potential sources of "code truth" : first the original folder in which I saved the Max project on its creation, second the *.amxd file (this seems to be a fully self contained project as well and most probably the "real source of code truth") and third - and this was a big surprise in the darkness - a folder that automatically was created in the place where unfrozen M4L devices are "unpacked" by Live (~/Documents/Max 8/Max for Live Devices) with a shadow copy of the orignal Max project ... and Live was not running!
4) Drag & drop the exported *.amxd M4L device into Live and opened it in the Max editor, where it reveals that it is a frozen device ... a shiny snowflake hints that this *.amxd file got it all ;-).
Unfrozen it and added anthoder live.comment (so that there is something to save and a means to force Live to reload the *.amxd) and then the most cruical part - FREEZE it first - and then save it.
Closing the Max editor and no error in the Max console ... strike & big thanks to Tyler !!!
... but 3 potential "sources of code truth" is nothing that should be called a workflow ;-).
I guess the "Max project" approach is also possible from inside Live with a *.amxd starter device (from the Live browser category "Max for Live"), if they are "fully self contained projects" as well (and not only the *.amxd that are exported from a Max project), but most probably they are.
And finally the mysteria of the defaulf project folders (~/Documents/Max 8/Max for Live Devices) in which M4L devices are unpacked by Live, when they are unfreezed (but as described above, also "populated" by Max), have to be demystified - when does the content of these folders really matter?
In which situations will the files in these "per M4L device" folders be used (loaded by Live or the Max Editor) - created on device unfreeze and gathered on device freeze only, really ?
This question also arise as I see a lot of "lost folders" of unpacked M4L device, which were not cleaned up.
Edit : the M4L that creates no error - all files are contained within the *.amxd.
I think I have sorted things out for a reliable workflow.
1 ) start with a normal Max for Live template from Live's Browser and save the *.amxd file into a location that can be easily backup'ed
2) create any further new files, e.g. JavaScripts or Max abstractions (that's what started my issues), via the project window of the device.
The project window can be opened via the "Show Containing Project" in the bottom toolbar of the Max editor.
Use the "+" menu of the project window and chose the appropriate menu item. Save the new file in the suggested location - it will be the project folder under "~/Documents/Max 8/Max for Live Devices" (on the Mac).
This seems to be cruical and you will see that Max creates automatically subfolders like "code" (for JavaScript) or "patchers" (for Max abstractions) and will move the files into this folders - although you saved them in root folder of the project.
3) freeze the device and save it - the *.amxd will be an fully self contained project
Which means the *.amxd got everything inside and can be transfered and used on another computer.
+++
But be aware of
A) The project folder created by Max for Live (under "~/Documents/Max 8/Max for Live Devices") still exists - it won't be deleted after "freeze & save + closing the Max editor) and can potentially lead to confusions.
This is different when you create a M4L device, even with several additional files like max abstractions and JavaScripts, in a development folder only and don't use the project feature - then each time the Max editor is closed, the project folder (under "~/Documents/Max 8/Max for Live Devices") will be deleted.
But it also will always be empty in this workflow.
B) Make your self aware if you freeze the device before saving the *.amxd or not.
Onyl if you freeze it before you save it, you can be sure that the current edits are all "packed & saved" into the *.amxd and its a fully self contained project again.
As long as its unfreezed its not - well, it depends if you have made changes since the unfreeze or not ;-).
C) Inside the *.amxd, which is in binary format but the most part is text and can be read by an external code editor like Visual Code, under the property "dependency_cache" there maybe a reference to the aforementioned project folder and one or several files you added to the project ... although everything is contained in the *.amxd.
Which might be the cause that the project folder mentioned in a) is not deleted. If something strange happens to your device, this might be a good place to look at.
I saw cases - and seems to depend on the way how you build up the project (add existing files), when you freeze the device and save the project the first time - in which Max abstraction files were also referenced in this "cache".
In my opinion this is something the Cycling 74 people should look into ... this smeels like a forgotten artefact.
D) Be mindful where you save your fully self contained *.amxd file or you might get confused by the "discarded feature".
If the folder in which you store the *.amxd e.g. also contains Max abstractions or JavaScript files you have developed beforehand (and maybe want to edit and develop futher more) and have they have the same name as the ones in the project, Max will take over and will do an automatic conflict resolve.
As this might happen completely silent (no popup dialog), you can still see that it happend as a folder "discarded" is created under the project root folder (under "~/Documents/Max 8/Max for Live Devices").
See also : https://docs.cycling74.com/max8/vignettes/live_unfreezing
So I think it's a very good idea to got a Finder or Explorer always open on "~/Documents/Max 8/Max for Live Devices" and the project folder underneath to see what happens ... because there are 2 "sources of code truth" (1st : *.amxd file, 2nd . project folder) and you are not in transparent control how these are handled and updated.
Hope this helps anyone who stumbles upon M4L device project strangeness ;-)