Remover

I have created a max external which loads fine. However, when I rebuild it with a slight change, it just keeps loading the older version of the external that I built previously. It's only when I quit and restart max that it finds the new one.

This happens when destroying the object and creating a new one / retyping the object name etc. after rebuilding.

Is this normal? Is there a way around it?

how-to-load-rebuilt-external-without-reopening-max

I'm no expert at this but I think you can set the Runtime version of Max as the executable (extra bonus, you can now debug as well).

https://cycling74.com/forums/how-do-i-debug-an-external-with-xcode-3-2

I seem to remember an article a while ago on how to set it up step, by step. I'm sure if you do a search it will show up.

I'm no expert at this but I think you can set the Runtime version of Max as the executable (extra bonus, you can now debug as well). 

OK, thanks. I'll try it and report back.


There is no way with a C-based external to reload without rebooting Max.

The scenario is different for java externals, which can be altered without the need to reboot, but you may prefer to develop in C for a variety of reasons.

I can't believe it! It must be pretty inconvenient to develop externals in C. Is there no way to implement this - even in the future?

Really? It's too much of a pain to have to reload max every time.

Specially after playing with Java and Javascript.

I am one of those who prefer to develop in C for a variety of reasons.

I guess I will use Javascript for the quick and dirty stuff.

I was hoping for a way to work with C the way I work with Javascript. You send a "compile" and it reloads the file. Why not doing the same for C externals? Send a "refresh" and it reloads the external. Is it hard to do?

Really? It's too much of a pain to have to reload max every time.
Specially after playing with Java and Javascript.
I am one of those who prefer to develop in C for a variety of reasons.
I guess I will use Javascript for the quick and dirty stuff.
I was hoping for a way to work with C the way I work with Javascript. You send a "compile" and it reloads the file. Why not doing the same for C externals? Send a "refresh" and it reloads the external. Is it hard to do?


Anybody know if there's been any change to this behaviour in max7. It really is a royal PITA

u guys are missing one thing . external file is loaded into a ram while your max application/patcher is launched. DLL external is locked there until u unload it/close the application that uses it . While u are developing your code how would it be possible for VS or XCODE to unload the dll under compilation stage that is used by another program ? Crash

JS for example is interpreted at runtime JS engine , this is totally something else .

???
u guys are missing one thing . external file is loaded into a ram while your max application/patcher is launched. DLL external is locked there until u unload it/close the application that uses it . While u are developing your code how would it be possible for VS or XCODE to unload the dll under compilation stage that is used by another program ?  Crash

JS for example is interpreted at runtime JS engine , this is totally something else .


http://gamedev.stackexchange.com/questions/221/how-can-one-implement-hot-swappable-c-modules

I accept it might mean big changes to the way Max works - and that it might create undesireable complexity etc. Also, this is a benefit to a marginal community relative to the whole userbase of MAX, especially given gen~ - so I'm not moaning if this hasn't been changed. The guys at Cycling74 know their code better than I do.

I'm just wondering if there's been a change in this behaviour in MAX7

eg. this suggests it's possible:
http://gamedev.stackexchange.com/questions/221/how-can-one-implement-hot-swappable-c-modules

I accept it might mean big changes to the way Max works - and that it might create undesireable complexity etc. Also, this is a benefit to a marginal community relative to the whole userbase of MAX, especially given gen~ - so I'm not moaning if this hasn't  been changed. The guys at Cycling74 know their code better than I do.
I'm just wondering if there's been a change in this behaviour in MAX7


are loaded at launch when they are used in your patch , And goes off only when whole Max application is closed (not only the patch that uses your dll). But that doesnt change the fact that is not possible to talk to max from VS or XCODE , they are not integrated in any way . If Cycling would build its own IDE with virtual machine then with some effort would be possible to make such feature working . Indeed that would be ideal for us .

#EDIT (answer to your previously edited post)
are loaded at launch when they are used in your patch , And goes off only when whole Max application is closed (not only the patch that uses your dll). But that doesnt change the fact that is not possible to talk to max from VS or XCODE , they are not integrated in any way . If Cycling would build its own IDE with virtual machine then with some effort would be possible to make such feature working . Indeed that would be ideal for us .


I agree with the above speaker. If Max had its own full blown IDE I would be thrilled. Sadly as it is for now, the nature of Max is still somewhat DYI/hobby. Connecting objects with cables is nice, but there is only so much you can do with it. Sometimes you just need to fall back to program code be it C or Java, especially when the programs are getting more and more complex. If other IDE's had the midi and timing capabilities that Max has, I would already switched a long time ago.

Well I'd have thought gen~ was a bigish step in that direction?

But yeah, I often find it easier to code things . I find the two work nicely together though. Some things come together more easily in patching, some in code. Max has opportunities to do both - gen, Javascript, Java, or C with varying levels of integration just in terms of the ones I've used. (I think there are externals for integrating python, etc. too?) The fact that it's made so easy to develop in C in Max is the only reason I'm able to whinge that I'd like it more if I didn't have to restart max to reload a DLL!

A lot of industries use visual patching tools now in professional environments though. I don't think the fact that MAX is patch-centric is a reason to discount it as only DIY/hobby: Labview and SSIS are two good examples of graphical "patching" interfaces that are widely in use by professionals. (Even if the latter is a fricking horrible environment to work in)

Well I'd have thought gen~ was a bigish step in that direction?
But yeah, I often find it easier to code things . I find the two work nicely together though. Some things come together more easily in patching, some in code. Max has opportunities to do both - gen, Javascript, Java, or C with varying levels of integration just in terms of the ones I've used. (I think there are externals for integrating python, etc. too?) The fact that it's made so easy to develop in C in Max is the only reason I'm able to whinge that I'd like it more if I didn't have to restart max to reload a DLL! 

A lot of industries use visual patching tools now in professional environments though. I don't think the fact that MAX is patch-centric is a reason to discount it as only DIY/hobby: Labview and SSIS are two good examples of graphical "patching" interfaces that are widely in use by professionals. (Even if the latter is a fricking horrible environment to work in)


It's most definitely possible to do dynamic dll unload/reload at runtime with plugin based applications in Windows. I use another piece of software designed for machine vision applications, which is a flowchart-based graphical development environment, and supports C/C++ dll plugins. It watches for any changes to the dll files in use, and if it detects a change prompts the user to reload the plugins.

Whether it's possible + how easy it is to do in Max though is another question. Also, given that we're no longer forced to debug in Max runtime (which made things like editing inspector values and debugging attribute accessors near impossible), I'd say it's not at the top of my priority list for the development team.

you can set an Executable for Run and choose Max7. Thereby whenever you rebuild the external, Max will relaunch. If you have problems that the old one is loaded, search and delete old .mxo objects and make sure there is just one filepath to the newly built external. As recently pointed out to me by Jeremy Bernstein, you can build for deployment or build for Development. The latter scenario better for enabling debug points. These are then linked to the process, i..e the executable Max7, so you can better investigate what's actually happening. MIB said the same above but maybe worth repeating anyhow. The flag NDEBUG can be added in Preprocessor Macros if you want to disable exception handling (try, catch exceptions and the like). So it is possible to develop with exception handling in the code, but if NDEBUG is added, this code is not compiled for your deployment(release) version. That's about as much as I know at present.

Max's class loader doesn't support dynamic unloading and reloading of externals. This is unlikely to change, so I recommend using the method @Venetian mentions -- set Max as your external's Executable and you can kill/restart the Max process when you want to test. Now that Max restores your workspace on restart, it's not terribly uncomfortable.

how to load rebuilt external without reopening max?