I havn’t updated my GP version for a while following the recommendation to never change a running systen so I’m not aware how stable GP and the Plugins I’m using are in the newest version. My older version (4.0.54) sometimes chrashes for some reason. The rate is let’s say once per gig. In order to make the GP up an runnign again quickly I wrote a watchdog script (windows) which is monitoring the GP Windows process an restarts immediately when it is exiting abnormaly. Then all I have to do is waiting till all Rackspaces are loaded (up to 20 seconds depending on the size of the GIG) and then select current rackspace by PC message sent from MIDI master keyboard.
Since for a while I never performed any GIGs without this watchdog script, so I wondered if this kind of watchdog couldn’t be part of future GP releases e.g. running another watchdog process in backgroung monitoring the healthy of GigPerformer (and all its instances) may be including the currently selected rackspace and restarting GP and reselecting current rackspace in case of chrashes.
I though I had to blame myself for this chrashes because I have not updated my version very often. So I don’t want to bore developers with issues on old versions. And since I’m assuming that also new releases somtimes are not very very stable I had the idea that a watchdog might help anyway.
It’s a bit more complex, not only stability but also usablily, change of features change of workflows… and it was my decission to not update very often and doing all the required learning on newest changes but making music very often instead. I hope this is ok for you.
Because it is is a simple windows batch file which is a bit specific to my workflow and requires a re-registration of GP gig file extensions. And furthermore it is not able to reselect current rackspace after restarting GP and reloading current gig.
So I didn’t want to expect other users to get involved with this kind of system changes. And I guess a watchdog released by Desktop Tech. would be a tool which is much more professional and useful than my batch file.
Yes I’m famillar with OSC and GP scripting and thanks for this tip regarding this interesting command line tool! Is this tool also able to ask GP for currently selected rackspace (polling)? Or is this Tool also able to be adressed by a GP OSC script in order to get notifications on each new rackspace selsction (Tool is UDP/IP server)?
Ok I downloaded this tool and it looks good. Implementing a notification interface to my watchdog seams easy.
Well, it might be worth seeing what actually crashed. However, going forward, if it was a GP issue rather than a plugin, then we would have to see the issue fail in 4.7
I have configured a variation in a rackspace to Bank-Hi=0 Bank-Lo=11 and PC=1 and I want to switch to this variation using this Bank Select and PC combination.
Am I doing something wrong or is it really not supported by this tool?
Other messages like making GP full screen or normal are workung well.
I doubt that that command line program is listening for messages (if it could do that you’d have to set a listening port and it would have to wait indefinitely for a response).
All messages sent back by Gig Performer over OSC will be legitimate OSC messages with OSC addresses, even if they are asynchronously reporting errors.
Is GP (OSC server) able to just reply to the IP/Port which client has used while sending it’s OSC message to GP? Clients port number is usually assigned by operating system and not known a priory (like servers are known) so I can not configure in GP → Options → OSC → Remote Client Port in this case
No - that’s on our list but some functionality is broken in the underlying libraries that we’re using which means we have to reimplement the OSC datagram ourselves, something that is not a high priority.
You can use OSCShark or Hexlar’s Protokol to monitor the results from Gig Performer using the ports configured in Gig Performer for sending stuff to remote apps or devices.
But as I said, that particular error message is not coming from Gig Performer
At the end of the day I just let GP write an appropriate sendosc command line to a dedicated 1-line batch file which can be used to switch back to the most recently selected rackspace. The watchdog script just calls this 2nd batch file as soon as GP has been restarted after a crash.
The “On Rackspace” handler looks somehow like (paths should of course be adjusted):
On Rackspace(oldRackspaceIndex : integer, newRackspaceIndex : integer)
var ret : boolean
ret=SaveStringToTextFile ("D:/GigPerformerSetRackspace.bat", "C:/Users/markus/Downloads/sendosc-win-1.0.2/sendosc.exe 192.168.178.34 54341 /GigPerformer/SwitchToRackSpace i " + IntToString(newRackspaceIndex) )
End
Works really well and no OSCShark or Protokol or any other command line tool is necessary
(I edited your post so that the syntax is clearer)
That’s a very cute idea, to use GPScript to create a batch file
Note that you can use OSC_GetGPListeningPort rather than hardcoding the port number - that might make things safer if you ever need to change the port.
Also, unless your IP address is static, you might want to use “127.0.0.1” to refer to localhost rather than an explicit IP address - again, just a defensive measure that will make the script less susceptible to changes in your system
so I’m not aware how stable GP and the Plugins I’m using are in the newest version. My older version (4.0.54) sometimes chrashes for some reason. The rate is let’s say once per gig. In order to make the GP up an runnign again quickly I wrote a watchdog script (windows) which is monitoring the GP Windows process an restarts immediately when it is exiting abnormaly. Then all I have to do is waiting till all Rackspaces are loaded (up to 20 seconds depending on the size of the GIG) and then select current rackspace by PC message sent from MIDI master keyboard.
