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

Dec 18, 2009 at 6:21pm

[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.

– Pasted Max Patch, click to expand. –
#47280
Dec 18, 2009 at 7:25pm

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

#170047
Dec 18, 2009 at 7:39pm

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?

#170048
Dec 18, 2009 at 10:58pm

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

#170049
Dec 19, 2009 at 12:36am

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

#170050
Dec 19, 2009 at 1:14am

thanks shane…be sharing again…!

#170051
Dec 20, 2009 at 2:06am

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

#170052
Dec 22, 2009 at 3:50pm

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!

#170053
Dec 22, 2009 at 3:52pm

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.

#170054
Dec 23, 2009 at 12:41am

Thank´s Peter :) Mailing you now ^^

#170055
Feb 17, 2010 at 9:25pm

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…

#170056
Mar 4, 2011 at 5:41am

@ 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

#170057
Mar 4, 2011 at 9:34pm

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
#170059
Mar 4, 2011 at 9:35pm

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

#170060
Mar 8, 2011 at 7:09am

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

#170062
Mar 8, 2011 at 8:22am

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

#170063
Mar 9, 2011 at 2:09am

%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

#170064
Mar 9, 2011 at 11:44pm

@ 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
#170067
Aug 26, 2011 at 9:37pm

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

#170068
Aug 28, 2011 at 7:57pm

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!

#170069
Aug 31, 2011 at 8:17pm

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.

#170070
Sep 1, 2011 at 5:33pm

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

#170071
Nov 3, 2011 at 11:02pm

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

#170072
Nov 3, 2011 at 11:03pm

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

#170073
Nov 5, 2011 at 5:02pm

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.

#170074
Nov 7, 2011 at 10:47pm

…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

#170075

You must be logged in to reply to this topic.