|
|
Nov 17, 2012 at 2:28am
Unloading mxe from Max memory
I cannot find this anywhere, but I presume there is a way …
How do I unload a .mxe external object from Max memory without closing Max?
While developing a .mxe, it is useful to test it, edit, and rebuild. But it must be released from Max before I can overwrite it with a new version.
I am using the Windows version of Max.
|
|
|
Nov 17, 2012 at 6:47am
Hi,
AFAIK, it is not possible ; and you must relaunch MaxMSP each time you change something in your external. Yep, it sucks ;-)
|
|
|
Nov 19, 2012 at 2:44am
“AFAIK, it is not possible”
It is, you just delete the old mxe-external and create a new one or click inside the box and type in its name again. Still annoying to do everytime but it beats restarting max.
FRid
|
|
|
Nov 19, 2012 at 7:23am
Hi,
@Frid : That’s true for an instance of a class (free/new method) but not for the class itself. Your bundle is loaded once and you can not release/reload it then.
http://cycling74.com/forums/topic.php?id=38217
|
|
|
Nov 19, 2012 at 1:10pm
The standard work-around is to build a new external (either .mxe or .mxo) and append a running number to it (myextern-1, myextern-2, etc. or similar). You can keep on doing that until Max runs out of heap memory, which is a pretty long time.
It doesn’t take all that much longer to restart Max than it does to do a clean build, so I’ve not found the restart procedure that terribly onerous. Obviously, it would be nicer if we could unload an external, and that’s something people have been asking for forever. Looking at what happens in an external’s main(), one can imagine that undoing all of that may well be non-trivial.
If it ever does happen, the next beer for the developer who implements it is on me.
|
|
|
Nov 19, 2012 at 8:41pm
Thanks for the confirmation of my assumption. I do see that many before me have lamented on this topic … but my forum searches did not find the previous threads.
The “standard workaround” appears round-about and not nearly as quick as clicking rebuild, but is less painful than restarting Max. For some reason Max takes forever to start on my system.
From within an app (like Max) it is not too difficult to purge a dynamic link library, but all instantiations originating from that DLL must be cleaned-up. That may be very tedious in Max.
|
|
|
Nov 19, 2012 at 9:15pm
I tried the “standard workaround” of appending a running number to the .mxe. The enumerated external object will load but not instantiate if the .mxe does not exactly match the object name within the module. I might be missing something.
|
|
|
Nov 20, 2012 at 12:35am
If that can make you feel better, restarting Max is what we do too ;-)
|
