Why does my standalone crash the first time it runs but runs perfectly thereafter? Or, trying to manage the idiosycracies of UDP/OSC in Windows using Behringer/Midas mixers!

Some brief background (as this is a loooooong post):

1) My application is huge but hopefully well organised with about 25+ sub-patchers and bpatchers. It runs perfectly every time I run it from the Max 8.52 editor.

2) As soon as I build it into a standalone, the executable always crashes on the first, and only the first, time it is run. Every subsequent run is entirely successful.

3) If I encapsulate the standalone in a VirtualBox, if the original standalone has not been run previously, the VirtualBox version also crashes repeatedly. If I run the standalone at least twice before encapsulating it (always one crash followed by any number of successful runs), the VirtualBox version works perfectly every time!

4) The crash takes the form of the top level patch window showing the spinning dial followed by the window greying out with a Windows system generated "not responding" message. I have to click the close box and then select the shutdown option to get out. If I do nothing, this apparent hang-up continues indefinitely with no measurable CPU activity or messages in the Max Console.

So what is going on?

The crash happens during an initialisation phase. I have gone to great lengths to ensure that this all happens in a very specific order as most of the modules require some form of initialisation routine and certain modules are dependant on others to have been initialised first.. I have painstakingly tested all manner of orders of initialising the modules and have been obsessive about eliminating [delay] and [pipe] objects in the initialisation routines to ensure that these processes are not colliding or conflicting with each other due to deferred scheduling. I also don't use Overdive.

After hours of testing, I have determined that the problem lies somewhere in this piece of code and almost certainly has something to do with the Max [udpreceive] object:

Some more explanation is useful here:

1) Max does not provide any means to request Windows to allocate a free UDP port as many applications choose to do - you must supply a port number.

2) Loads of people have reported problems with [udpreceive] failing to work in apps that are run repeatedly using the same port number until Windows is rebooted and I have found the same thing.

3) This routine creates two almost identical portals though which I communicate with a Behringer X32 Rack mixer and a Behringer XR18. Both Midas and Behringher have adopted a very strange protocol for using UDP. Rather than recieving and sending messages on adjecent ports, as is the common method, they have chosen to both send and receive on the SAME port. By default, this port 10023 for the X32/M32 series mixers and 10024 for the XR/MR 12/16/18 series mixers. I don't know about the Wave series but I expect it suffers in the same way.

4) Aside from the problems with [udpreceive] failures mentioned above, [udpreceive] also fails to work if it is configured with the same port number as the [udpsend] command. In other words, it simply doesn't work with these mixers. Yes, I have heard some people talking about broadcasting the sent messages but in reality it doesn't stand up robustly for any length of time.

5) Having opened a UDP port in Max, there is no way to close it again and I think this explains why patches don't work when run repeatedly - neither Max nor Windows are releasing the port.

However, using the equivalent Sadam UDP objects DO work and they work reliably and persistently even when the send and receive ports are configured to be identical. It also works on repeated runs of the same patch. So what are the Sadam routines doing that the Max ones don't?

The one problem with Sadam is that it does everything in OSC binary bundles and "streams" and regardless of how many times I read he help pages, I can't figure out how to convert normal, text based OSC commands into the correct format.

Then I discovered a workaround published elsewhere - send the textual OSC commands with [udpsend] to [sadam.udpReceiver] via the internal loopback (localhost or 127.0.0.1) and send the replies via [sadam.udpSender] to [udpreceive] - and blow me it works! Perfectly! Every time and for hours on end!

So how have I tackled the problem with [udpreceive]/Max/Windows blocking up ports? My solution has been to reconfigure the port numbers randomly every time the routine is reset. I have chosen to use adjactent even/odd ports in a rarely used block from 15000 to 20000.

As stated previously, the [udpreceive] object MUST be defined with a port number. I've tried all manner of port numbers in different ranges and it seems to make no difference to the crashes mentioned above so before anybody suggests that it's because I've used [udpreceive 0] as a starting point, I can assure you that it makes no difference what port number I choose. Once the object is defined though, the port number can then be changed any number of times, which is what I do with my randomiser.

So does some mega-guru out there have any suggestions? Why does this "one-time" crash occur, why doesn't it happen on subsequent runs, and how come I can get a reliable VirtualBox package to work provided that the executable has been allowed to run and crash once before it is encapsulated? Is it something that has been introduced and/or made worse with the Max 8.5+ upgrade?

And for all you Behringer/Midas users out there who are pulling your hair out trying to interface to your mixers using Max, this method does work!!!