Andy Maskell

I have a very large and complex standalone that I have been writing for ages. It mostly processes MIDI and a bit of OSC via 19 MIDI ports (both input and output) and 6 UDP ports (2 in, 2 out, and 2 bidirectional) so there is a lot of I/O flow going on.

When I try to close the standalone, the display window closes and it appears to have quit but I have come to realise that the process is still running in the Windows task manager. What info I can glean is that a thread involved is waiting for an I/O process to complete. I have to kill the process in order to dismiss the remaining threads to be able to run the standalone again or to free up the Max runtime loader to re-compile the executable.

I have no idea where this presumed I/O "pending" action might be. The only thing that I can think of is that the devices and software that I'm controlling send a lot of Note On messages without the need for corresponding Note Off messages so there could be a problem with the runtime platform closing if the MIDI buffers still contain those "hung" notes.

Any ideas of what I might try? Can I use 

I've tried using a [closebang] triggering (;max clear) and then (;max quit) messages but that makes no difference.

Any ideas of what I might try? Can I use [closebang] to send a KILL message to [shell] so that the standalone kills itself?

I have a very large and complex standalone that I have been writing for ages. 

how-to-kill-a-standalone

As much as I don't really like it, sending a 

As much as I don't really like it, sending a (taskkill) message to [shell] does the trick!

what about "dispose" (thispatcher) to toplevel window? (i have not much hope, but i see that it has not yet been tried.)

but with max itself and the structure of the standalone - I mean what all you left included.

It should not be that your standalone shares same process ID

All that has to be set in standalone inspector.

In addition, max 8.5 and up initialise node.js even if one does not use it at all, which causes slow start of Max app, and who knows what else.

If you can, use older max version in case all this new added stuff is not necessary.

I am mostly running 8.1.11 compiled standalones.

There are quite some posts about that hanging max problem

that problm has nothing to do with midi,
but with max itself and the structure of the standalone - I mean what all you left included.
It should not be that your standalone shares same process ID
with max runtime itself.
And preferences etc.
All that has to be set in standalone inspector.
In addition, max 8.5 and up initialise node.js even if one does not use it at all, which causes slow start of Max app, and who knows what else.
If you can, use older max version in case all this new added stuff is not necessary.
I am mostly running 8.1.11 compiled standalones.
----------
There are quite some posts about that hanging max problem
on windows and suggestions - solutions
amoung which taskkill.





Maybe you can build a close routine that can prevent the hung state. What if you remove all midi objects before cĺosing? Or do you use 3rd party externals that might cause the issue?

 from the top level window and it used to work fine.

@SourceAudio - I think you have hit the nail on the head there! The problem has only appeared recently and probably coincides with the upgrade to v8.5+. I see that they have added an option to 

 to avoid loading some of the unnecessary stuff but it does appear that there is still a raft of things being added to my build that I don’t need!

@11Olsen I had a closing routine that worked fine until recently (see above). The only 3rd party externals I have included are yours! 😂🤣😂

 does the job even if it is a bit of a sledgehammer. If v8.5 has introduced problems then I would hope that C’74 will fix them.

@Roman - I was already calling (;max quit) from the top level window and it used to work fine.

@SourceAudio - I think you have hit the nail on the head there! The problem has only appeared recently and probably coincides with the upgrade to v8.5+. I see that they have added an option to [standalone] to avoid loading some of the unnecessary stuff but it does appear that there is still a raft of things being added to my build that I don’t need!

@11Olsen I had a closing routine that worked fine until recently (see above). The only 3rd party externals I have included are yours! 😂🤣😂

For now taskkill does the job even if it is a bit of a sledgehammer. If v8.5 has introduced problems then I would hope that C’74 will fix them.

There is one problem with using taskill :

Max stores preferences and audio settings

If it does not quit properly, it won't store any of that.

To reproduce that problem it is even enough to set window noclose

message to quit Max - preferences will fail to be written.

I would really encourage you to get that standalone

If you need any help to clean it up, or revert to older version,

There is one problem with using taskill :
Max stores preferences and audio settings
on quit.
If it does not quit properly, it won't store any of that.
To reproduce that problem it is even enough to set window noclose
flag to thispatcher and use 
;
max quit  
message to quit Max - preferences will fail to be written.

I would really encourage you to get that standalone
quit properly.
If you need any help to clean it up, or revert to older version,
just ask.



@SourceAudio I’d rather it quits properly too, even though my standalone doesn’t affect any of the things you mentioned - it really is just a mega-complex MIDI data processor. In the morning, I’m going to re-install the last version of Max that I used before upgrading to v8.5. If that solves the problem then I’ll submit a bug report to C’74.

@Source Audio - Well, some interesting developments!

Firstly, I tried going back to v8.1.11 but it made absolutely no difference.

Then a thought crossed my mind - I had noticed that the software I interface too that depends on UDP/OSC to work, seemingly creates its UDP ports with random values. I tried this myself and it completely fixed a long-standing problem that I have had where restarting my app would cause the UDP Tx/Rx to fail. Reading around, it would appear that Windows 10 does not implement UDP protocols robustly enough, especially when the same port is used by different apps or instances of apps. Explains a lot!

However, having tried to go back to v8.5.2 of Max, I am now experiencing a completely different type of standalone crash that I have never seen before. My patch works perfectly in the editor but the standalone just hangs after it has done all it's initialisation routines.

Another uninstall, reboot and reinstall of Max underway...........

Hopefully, this is my final update on the matter!

Having struggled to get a fully working Max v8.5.2 back on my system (it took three attempts!), I now seem to have a standalone that works properly again.

I think the two main things that sorted everything out were the randomisation of the UDP port numbers, and removing all the resource folders from my project folder and letting Max rebuild a new set from scratch. My standalone now loads much faster, runs without crashing and exits properly. Plus the UDP/OSC and MIDI link to the software running on my iPad also runs without any hitches.

I now just have a logic issue to fix in my analogue clock/alarm/timer routine but I think it could probably do with a complete re-write at some stage as it has become over-complicated due to endless features being added over time.

But hey-ho, it all works again now and better than it ever has for quite a while.

How to kill a standalone?