wchapin

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.

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.

unloading-mxe-from-max-memory

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.

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.

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.


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.

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.


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.

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.


If that can make you feel better, restarting Max is what we do too ;-)

Unloading mxe from Max memory