Forums > MaxMSP

[sharing is fun] Quitting, then relaunching your standalone application

December 18, 2009 | 6:21 pm

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.

– Pasted Max Patch, click to expand. –

December 18, 2009 | 7:25 pm

Synchronicity!
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
Thanks much

Shane


December 18, 2009 | 7:39 pm

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?


December 18, 2009 | 10:58 pm

"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….


December 19, 2009 | 12:36 am

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.

Shane


December 19, 2009 | 1:14 am

thanks shane…be sharing again…!


December 20, 2009 | 2:06 am

Hi Peter,

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.

Sergio


December 22, 2009 | 3:50 pm

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!


December 22, 2009 | 3:52 pm

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.


December 23, 2009 | 12:41 am

Thank´s Peter :) Mailing you now ^^


February 17, 2010 | 9:25 pm

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…


March 4, 2011 | 5:41 am

@ Peter
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.

@ stephan
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


March 4, 2011 | 9:34 pm

Shane: it very well may be possible to restart MIDI Ox in the same way I quit/launch the standalone. It really just boils down to launching a .bat file from the max patch. Try the attached .bat file

Attachments:
  1. midioxql.bat

March 4, 2011 | 9:35 pm

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
cd "%PROGRAMFILES%MIDIOX"
start midiox.exe
exit


March 8, 2011 | 7:09 am

@ peter
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.


March 8, 2011 | 8:22 am

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
cd "%PROGRAMFILES%MIDIOX"
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


March 9, 2011 | 2:09 am

%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
cd %PROGRAMFILES%
and you should end up in the Program Files directory. You can find out just by typing
cd
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
C:Program FilesMIDIOX


March 9, 2011 | 11:44 pm

@ Peter
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!

[attachment=156039,1904]

Attachments:
  1. batchnotchangingdirectory.gif

August 26, 2011 | 9:37 pm

@ Peter
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.


August 28, 2011 | 7:57 pm

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!


August 31, 2011 | 8:17 pm

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.


September 1, 2011 | 5:33 pm

I’m guessing that is not for the midiin object, thought? For notein/ctlin objects only?


November 3, 2011 | 11:02 pm

@pnyober yes I think I got rid of MIDI in in all my patches and used the individual objects ., ., I forget why.


November 3, 2011 | 11:03 pm

Does Max 6 solve this issue or provide a better solution ?


November 5, 2011 | 5:02 pm

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.


November 7, 2011 | 10:47 pm

…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


Viewing 26 posts - 1 through 26 (of 26 total)