XP collective/standalone problems
Dear Max people,
We’re having a terrible time making collectives and/standalones in XP. Our patches were done on OS 10.4.10 using the latest MaxMSP+Jitter releases as of today (4.6.3). We’ve run them on our XP machine, made collectives/standalones which work fine there, but when opening either on numerous XP computers, with and without MaxMSP-Runtime, we constantly get "MaxMSP has encountered a problem and needs to close". The only error we can see is "recopy failed to get string STR#7519" but we get the same error message on the machine that builds them/runs them fine. I’ve done this many times before
and never had a problem up until now. Any ideas?
I’ll attached a short collective, built on the XP machine (but also runs fine on Mactels).
do you have full QT installs on your XP machines? needed for Jittah…
Hmm, that sounds simple enough to work. I’ll have to check on Monday but that’s probably it.
Oops, spoke too soon. Yes, a full install of Quicktime WAS on the XP machine. I updated and upgraded to ‘Pro’, but no go.
Any other suggestions?
On Oct 14, 2007, at 11:23 PM, Christopher Keyes wrote:
> Oops, spoke too soon. Yes, a full install of Quicktime WAS on the
> XP machine. I updated and upgraded to ‘Pro’, but no go.
> Any other suggestions?
Java install, could pose issues. To disable Jitter java support put
"jitter java 0;" in a file named jitter-config.txt in your search path.
For more info on this issue and the fixes for Java 1.6 in Max 4.6.3,
search the forums.
also, if your patch has a jit.qt.grab that initializes on startup, and you don’t have the VDIG or whatever stuff in there, that *might be an issue. use jit.dx.grab…
I’m trying to open it with 4.5.x. on XP, so maybe this isn’t helpful, but:
- Max/MSP starts
- Jitter starts
- Patch opens
- For a split second I can see a patcher and a jit.window
- Max quits with no warning, no dialogs, nothing
What happens if you don’t open the jit.window?
Is there a loadbang or equivalent that "autostarts" the patch’s functionality? If so, what happens if you disconnect it?
Thanks for these suggestions. Unfortunately I’m still having problems. I’ve tried the java disable with "jitter java 0;" I have been using jit.dx.grab, deleting the jit.window and other automated start-up items; no change. I am using one non-standard object (cv.jit.HSflow) but deleting that has no effect either. Other patches are loading but I get no audio. I am now getting error messages now though:
"Run a DLL as an App has encountered a problem and needs to close. We are sorry for the inconvenience."
"The procedure entry point swa 32 could not be located in the dynamic link library jitlib.dll"
I’ve attached the patch but not all the rest of the subpatches.
Any help appreciated,
By accident I built a standalone and forgot to change the [jit.qt.grab] object to [jit.dx.grab]…but it now runs, except for the camera (I checked it playing a movie). Of course I get errors about [jit.qt.grab] unable to open device, but aside from the camera, everything else works fine.
Can anyone explain this?
I didn’t follow this thread in detail, but I remember that in some state
of Max (4.3 or so) standalones on Win XP
1. had to be named differently to the name of the patch they are made from
2. could not have a Version number like myapp 1.2 (where the dot was the
i didn’t check lately. just a shot in the dark.
Christopher Keyes schrieb:
> UPDATED WIERDNESS,
> By accident I built a standalone and forgot to change the [jit.qt.grab] object to [jit.dx.grab]…but it now runs, except for the camera (I checked it playing a movie). Of course I get errors about [jit.qt.grab] unable to open device, but aside from the camera, everything else works fine.
> Can anyone explain this?
I did make that mistake in some of the earlier tests, but not on later ones. It seems to be a problem with jit.dx.grab. If, on a windows machine, I build an application from my patch with jit.dx.grab, the application crashes on other windows machines. If, for some perverse reason, on a windows machine, I build the application with jit.qt.grab, it works fine on other windows machines, except of course for the camera…go figure.
On all of the machines I’m using the latest versions of MaxMSP+Jitter; 4.6.3 and 1.6.3.
For anyone who happens on this thread, the problem was that
[jit.dx.grab] did not seem to like the ‘vdevice’ attribute when building collectives and standalones. [jit.qt.grab] was fine with this.