[sharing is fun] Quitting, then relaunching your standalone application
I’m sure someone will need this at some point….sharing may be fun, but stuff like this is very UNfun.
Here is a hack to quit, then relaunch your standalone application. I suppose it could be used for Max, too.
This has methods for both Mac and Windows. The Mac version uses applescript and the shell external. The Windows version uses the java class DOShack to launch a bat file.
It’s ugly but it works. Even if you are not familiar with using .bat files or applescript, there’s pretty decent explanations in this patch.
I needed to do this to make a testing application for our midi controllers at Livid. Since Max doesn’t refresh the ports when you plug/unplug a USB MIDI device, the testing app standalone I made has to quit then restart every time I plug in a new controller. Pretty irritating for the testers, so I cooked this up to save some hassle.
----------begin_max5_patcher---------- 2817.3ocwaE0bahjD9YmeEyRU4hcJaYlY.Dx6sUc416tsRUaxlKYuGt5zVaM BFYgMBzBirr1T4+90yzHIrCfPwxvV0ZBnYflutmt+5tG97KNwZR58xbKxUj+ G4jS97KN4DykzW3jhyOwZt39fXQtYXVyk44hqkVmi+lRduxb8uebFLNRrXYR vreeRV5pbYFYlRs3pKubZlHIHMJefbYnLevzLoD9yk4oSUqDYxAyTy2bCiiR jAoKSL2UmhKlrbd5RUrTYjAZwUmllnxi9So9ZiFXWbUbfp0Kj3qkkE42J9oE YxbYhRnhRS98LYfBGgiuGLaByloOXW7mcyRnBlEkbcoY35aFEanq9.kZlniW oIEEZPkzI2bgqmUIANQL2HXVuIKRDas6ELJYy6GSesu7hWn+y4OmpkUqVMHN 5tnvnjbU1x4.1jOHHsZcAqazEinFHkOps5BGeTI3XNvXFcAysFcgaGnK.DTC kektvH7jIqIePp.kv6WOIUlMNYAb1e6wpgCPEXWgJvXQ1HPycGh.sSaAZtmM Bz3ANWePO8JAZmCDnoGQf9zaVlqHyE2JIBRhbEYZTrjDkPdepR9AQ34DQRHI WbG764jwV+wxHEtBYvDgZr0.xGitdl5hf3nfaIoID0LIdOToDYXjhDoN6YWC 4PcP2J9sVCgtkbXn2ITeUqFh1iZnWuNcInYjgZDMSC1jG.14JPCIhSSjuJmD EjlbNIWFCunf15SyRWQ9fH3VveG4GAYWudYrkddIjzER7NDT7CFU8hkJB7Dy HhEKhk4AYQKTl+cTfA001FvjfHQjecVTtwzAdtJhTjuVKhgQvJynIKUxu6.B TUodmtO8Nywrxzyyt05ciqO2QlCbpIZld4ckpc65U6j2pD.jbzz9vRO3Q9UJ +qEJIgQnVUBZrp.M6FBob9CBq70nCcD5vxy.OH3R8qFcbF0AwGpAVTDlUqiw 1DhDosIaAffNxw.l0BHC6.uD0.HvJdxpnjPfyxwwTYhH45VatfNQ8bZDc75O zIijlebrWZEbXWv3sQ33PC5ae7Y5dMbqWmqjyKAO8.OVJ2GshZM8J2ByNiWJ edSrXc38HK1+5EDcrvEjYgD8ilXcDi8QYFd+zgsl9ew5Tlw.mLxfazQ0fard jxiRSrPrZ5xX.+VNcJANUy.B4.IBLFnjoo.Ikj0j7Eh.MEjcbO0h64jUyhfb HxmIiiIgRQbN3gTMSONfoaZxEHworPxJwZyM6ch6GT45.2ipZCy5Zjc6UalE F7B8sqY9CsqQu0mTUMDBgAA4kkijH2QN0nCAwIDnk9t0uYwh2CmL.HVpygvL Q.tiA9mYoSDPheSjjLoJSFcmzbwqyDymCfYfHNd8.xaeEnUik57RTyDJcxIh Dh7dYVPTtznNAA36Hucp9HnhACFM+4kZqjHi0Bnt0WRksVSeETrmqGp99tgs 8R3NARq3dfxrHeKsXBZesgsr1pqLYY3QCoFsMQJ8Oiz1WDCFpUagwOhICMDI 0Raq80PLSHLFtMx7qtnV18n00THqSSFHP9Jf9c9o2c13jOON4NAXmA4mn9D3 qM4ZxOPtaf47SA01Xqy9dbH.2fOHf0++P4AO3lznDXbiK9uhwi5fSAjnXV5K 9kJ0bdsVyMZuYwhIyfDGZUxLXZLEkXi5ZT7d03QmOpG0cv5f.ArZRuVLLM4U JxLboqdAVg9bvM5TSuQbm.WHcNQmlodsYT9UVGQX1D3yixZOLaFkKlUTQNmz ZRZj62AvrFWgLrUoIUiK7pbb3umDCO+QoCsU48uWB5f+B4iRrvOVMfTbjZAZ ONj0TQU3C6Q6w2.tnyR+ikRSv+zoDccsTvKy4XsQxJdWMW4wQxJUMjCfPm+d KlAlcIuslkn4HsvEf6lbNpDqc5U1bOL9ngi.DgNNFxV8.VXu+HeHBxOfpAgg 9J7ehyiUCyJNumwvwVK.oGbQpAPMw3EQgmS.2.D4zovqDvTxXMCDWBxj5BGI HbRNDpBHpDBFzqQtuSL0V2PO4IxEY+tZsw5xhUcqUsn.Sd1wEMt8L9Z40PGg 2gEnq1Bn+egPZA.2SHAizhlGQDKUo.YUfIHZyCl6YoywbQFTPqb6XzZzDHMb Qn1QzXKccYgqMQBAEwPjl487WEcpIACG5At7wEamD2twtbP6SWP+ie4SyDA2 d0SsIqG.ZuqHRU18A2RIAR8GgmUCx0mozozYOWt7+kxdS2HgTSjywIn+E93j Mq.paJGwzepx6gwfbSA33XKdpFVqlN7OBw5ijYj+dZb3yN3p8mStHA7RGmB4 0NKMGPx.cFxu7Ce7W9oO9l28ud6O+O+zKGOdG.NFRVA7VHxTjcoQC48NNQde j5o1wk8ftXWxvDFYXWMcqidma2gu0T1WvMG3JMjXPqNn9uNN3livczl7vpu9 ubZ+UNbXsJw93fGl1DzbeV8JsWC3rAt0iIdz9e2en8l8DqEdoEQGl8C2eHlf IRo2q.wpt2j98Y22lPlbbayzdsibvz0Y1z8aG41EYVVmczC2fDVO+VMNtEti wtg31jWGlW+Y0L+9aHE7vrNRzn13vEW2Lrwtyxb6QihsQp6.6AlS4d3WjZac 0ysGaNloL7PpP5jYGrsf45ZzKunfDYQkCz8GPhi4c+mO8qjXcltPpr45VpME HR.7IDecCGPVQmVzXG3DRzTcC.RzrtfwavtyLkwONM81b39dqzzcfqdVIoVP 9misuj46zTE286OZB8gadFytzNTrY27C66NcYLdw9Kp1k5exCJ1ko4TqLc1p vrMOJTtaGVsIGoE3lz5U4a2lVWVXZ+5iXd+0VALzQJG6DesUrk0eFia3xWzq ftfMOlrCZPhrXqM1hS+AL5BKkud9jzXqi7t0nVHwq718olJNS48GjbSNYWKk 5LTAOLj1HpLp+WAoKuXmAJ3lSwyqIPgY2i6atEYQIpoDXED79QdY9Ky06IgK 25DtDcd35cfaGdQs.GUpFK042gNrGSBL8P857D8DyPpr39ZnVDoG2kg+YLIG hmK6rcqK1iDF2fHNMVtIpa+YoDmJBQBfGAmN6uPAk2ClM2pdpeetkTAYeVW4 GtXmoxaLjMi0+aI0bHBE3mUiMO.fdV2Vp0hZEMgztwuSJFu+VZYR93.71vZ1 aSKWbsoO.tM0tbJq6q2xyXLHLmcG6h2YzYaceEiceYreNquX4uPJlqeiIB0e KExjWKueA4zAu9pyNUuU9tbvqOqZ3w8aIPb4+uEvE1Dc+FKIYWzBnEhD4161 jqCRiSyPA0dvHaWeeFHeXq9Kc5Vos5xKLIMKTlU1RKC7MGJCK63o9O5NZwWe EtQ730VFeVmhB5+0HeamB73aAEZbeUP8qdSvzNnqntXEkNzwGqYXcNf36E4L SyDV8QeR6lms95ODNySWlErYAQQ02H6d3gxbUTBtk31MF8mHFgtcPyhBCkIk gv4QgKRiRTEx.42pT21VQ5QOtpkI2GJ36UlXrglhPNp36Ekt8rigztODjcXB KERazU6klWjRvlSdpxZq011cm11qMxzvtUlbZiL40oxjNKm8KS7CSlPSKJ5Y yc2IOU7qEhptnGcnSEZaL8YNcqJ0qs3T2IS71fSGnHw4nkkCE2CI6N6oJrz1 nTc6T.j0Fk5iD7maYZXKBn1wl971n4r6VMmcKjI2N0qUqDIJqagoV4cuaIQP aCILJuawo1HRcKGBVqjotUy0BWSzt0CN0sExDqaYuzFxeruMxeXofJcxSTVc aSzFV2Z361FVMdcqkuWaHu35+DjI3ju7h+Ov7iPf7 -----------end_max5_patcher-----------
Exactly the same issue here at Akai! I know we’re competitors as companies but as coders we can help each other out. I came on the forums right now to ask about a solution to this exact issue, for testing! Hope this works
Ah, re-read… relaunching the app is the deal itself. A script that does it isn’t going to cut down the time too much.
Maybe this is a request to Cycling then after all. Refreshing the midi ports like u can do in midi ox is what I really want.
Personally, much props to you at livid for building in America, but I have to make things easy for products shipping tens of thousands of units. Multiply that by the time it takes to restart applications which test products that do multichannel audio and it’s a LOT of time.
I hope this script helps some right now but maybe as companies, to a company, we could get Cycling74 to make a refresh midi ports option within their program. This issue becomes most problematic for companies making many units with standalones and connecting multiple units. I’m not sure if Cycling reads these forums avidly, but maybe we should write them lividly and ask them for this feature in an update?
"A script that does it isn’t going to cut down the time too much."
It’s certainly better than having to do it manually, but, yeah, a true refresh of the ports would be great. I, and others, brought this issue up on the max5 beta test a few moons ago. It has apparently been a problem since something like 1924 :) and there is no fix in the near future. So, yes, they are aware of it, but it’s a lot of work to fix it.
One possible solution for you is to route the midi to the testing app via maple or yoke, that way the max-based tester is freed from the tyranny of its inability to refresh the midi ports. Since midi ox will NOT need a restart on re/plug, let that handle the initial midi config and just have it route the input to a loopback to the test app. Jeez, wish I’d thought of that for myself! However, I think, for my purposes, the relaunch is the way to go….
Yeah I actually did think of that but for our testers, well, they don’t speak English and it has to be very simple. Something you luckily haven’t had to deal with is the windows class compliant driver issue when sending sysex to max. Some of our products have test modes you see as not all the buttons send midi, rather they are for top panel functions. So in test mode they send sysex but max crashes!
Anyway, no control over the core stuff…this is what we get for using such a fast for audio/midi but high level language.
For those of you out there doing performance or installations though the routing through midi ox solution can be helpful in case the jig gets loose or u need to plug stuff in and out on the fly without shutting down.
Oh an Pete I’ve been a fan of your video max patches for a long time. You an VJ Fader really push the envelope with Jitter.
thanks shane…be sharing again…!
Do you have a version of the shell object that works on OSX intel macs ?
I can´t seem to get the shell object to work in max 5 or 4.6 :(
I did notice the source code is available but i´m not familiar with compiling objects. Any help most welcome, thanks.
hmm…yeah, Jeremy Bernstein I think took over maintaining that external. It seems like it used to live on the c74 share site, which has been gutted for the new website. I can email you the copy of shell i have, but I hope it becomes public again!
hm, guess i can’t email you from your profile. i’m pnyboer a slambassador com – send me a mail and I’ll send you shell.
Thank´s Peter :) Mailing you now ^^
In my experience, it is fine to close the patch and reload it to make all midi stuff recognize the new ports. If you work global it even works without reloading the patch.
As a standalone isn’t more than a runtime, you could maybe have two collectives in the bundle, one to close and reload the main patch, or even better, have only a Midi receive patch, which passes on the data with send/receive and just close that patch and reload it…
Just thinking further, it might be sufficient to script replace the offending midiinfo…
Just made a quick test, it doesn’t even need scripting, banging the midiinfo does update the menus in the helpfile. Maybe it has been fixed in the meantime…?
Matters are much worse with audio interfaces though. Max/MSP is still the only audio program I know of, which cannot deal with plug’n'play interfaces. Even if you reload Max and it doesn’t find the last interface Max can’t switch to its fall back (the internal) interface. It just looks like it does, but it doesn’t work…
I hope that c74 will sort out this for the future. It is essential and crucial for any live musician…
Somehow this has become a major deal. If I can’t find a way around the restart time I may lose my job – as this affects all test apps on all products. I am frantically looking for solutions on PC – I do not know other programming languages so am not familiar with the batch files or java objects used to control them. Would it be possible with your patch to send a message to restart MIDI OX ? MIDI OX restarts very fast you see and will remember its routings as well. This would be a life saver but I do not know how to do it.
was this on mac? because it does not work on PC for me. un plug a device and plug back in, bang the refresh for midiinfo and the list stays the same, although if you send this to notein or the like the port has not been refreshed and no data comes in
and for the sake of instruction in one place, here’s the contents of the bat file
taskkill /IM midiox.exe
ping -n 1 localhost
Thanks so much for this!
Currently I can’t get this to run standalone becasue I get the message
(mxj) Unable to resolve path of max.jar! mxj is rendered powerless.
Unable to create JVM
All the help forums on that are for mac (this must be windows) and I’ve tried copying the whole java folder to no avail.
Frustrating to be so close… if you have any tips much appreciated, otherwise thanks a bunch.
OK i got the mxj working in standalone. you need to put the files in the same locations as described here http://www.cycling74.com/docs/max5/vignettes/core/standalone_platform_win.html
and NO where else… and including the whole java folder messed it up too. U can only put in what you are using.
I tried to mess with this line
so that the standalone would work in drives other than the C: but it didn’t work. it’s probably easy to do this but I’m not familiar with DOS commands
%PROGRAMFILES% should resolve to wherever the Program Files directory is. It’s just an environment variable. Here’s a list of some common ones: http://vlaurie.com/computers2/Articles/environment.htm
So if the bootdrive is on D:/ and MIDIOX is, therefore, installed on D:/Program Files/MIDIOX/ this .bat file should find it.
You can test this by opening a shell (go to the Start menu, and type "cmd" in the run field) and try something like
and you should end up in the Program Files directory. You can find out just by typing
and it should tell you ("cd" is like "pwd" in unix).
If you need to be explicit for some reason, then you can change that line to
Thanks for all your follow ups. I suspected the "%" around the directory did this, however you can see in the attached screenshot it finds the explicit directory but does not switch to it. If the batch file is run from the external this happens, if it's run from the desktop on the C:, it's fine.
I don't think this is a big deal at this point though.
Thanks for all your help!
Well looks like all the routing through MIDI OX, although faster for a refresh, is too cludgy and my boss needs it to be better.
- you have the ping at just 3 to restart max, but when i have it set that low it seems it’s not enough time, that max hasn’t released the ports yet and when i restart they still aren’t available. My guess is that this is machine dependent (2.4 ghz windows dual core 2gb ram) but perhaps you ran into this too… or there might be some other variable that made a ping of 3 work ?
Cheers and thanks for all your help.
hm, yeah, I dunno, it probably is a machine-dependent thing. I’ve had the delay down to 1 second and it works on some computers….what a drag!
I want to add a follow up, in case someone else is dealing with this somehow. I was able to get a 1 second restart IF the device is unplugged first, then you hear the device unplugged ding, plug in the device again, hear the ding, then refresh.
I’ve tried in on a couple setups so far, about to try on a much larger patch which does audio.
I’m guessing that is not for the midiin object, thought? For notein/ctlin objects only?
@pnyober yes I think I got rid of MIDI in in all my patches and used the individual objects ., ., I forget why.
Does Max 6 solve this issue or provide a better solution ?
Apparently not. I just tried a patch with [midiin] with an Ohm64 attached. Midi rec’d fine. Unplugged USB. 2x clicked on the midiin object, and the menu was correctly updated that the Ohm64 was gone. Plugged it back in. Ohm64 shows up in the menu. Selected Ohm64. No data rec’d.
…blah , it’s such an important thing too for live performance in case a cord gets pulled so you don’t have to restart.
I gave them a call and they said they were aware a few months ago but could not say if it would be in Max 6… I guess it’s not, hopefully, yet
Forums > MaxMSP