Running into issues building legacy applications
Hi.
Some background - roughly 10 years ago I developed an installation with a well established artist. It is now slated to be shown at a museum as well as in a gallery survey of his work. The piece was built using Max 4.5 and Jitter on what was at the time a very beefy PowerPC mac. The patch won't open in new versions of Max and I have been unable to install 4.5+ Max + Jitter on newer Mac OS due to what seems like issues with the privacy package. We would rather not ship the original Desktop PC, and obviously it is desirable to unencumber the work from this legacy architecture. It does appear that newer versions of OS X can run exported 4.5 applications but it's not quite that simple... hence this thread.
Basically, whenever I try to export an application or a collective, Max crashes once the app is about 1.1Gigs. Since the piece uses 2+ gigs of video, this is an issue. As a work around, I'm wondering if anybody knows how I can manually edit an exported application or collective to include the video resources. I'm thinking that I could export the application sans video, and then open up the package and manually include the various files that cause it to fall over when I'm building the app. I have tried inspecting the package contents and have had no luck there - it doesn't appear that there is a straightforward directory where resources can be included. Apparently this changed on newer versions of Max.
Any advice would be appreciated. I'm also open to alternative suggestions.
Thanks,
Sam
why do you want to include videos in an application at all?
I'm open to other ideas but it doesn't seem to honor the search path if I don't include them. Perhaps I've made a mistake. Some guidance would be appreciated.
from what i know, search path in all v4 is automatically everything beside and below the executable.
Thanks, I'll try that. I believe I did so before but I'll give it another shot when I'm at the studio next.
1. it is clear that max 4.5 won't run on newest Macs.
2. if You have a patch, You can port it to max 6,7 or 8
depending on ev. used 3rd party externals.
3. that could be solved by forcing Standalone App to 32 bit mode,
in case it runs on MacOS up to Mojave.
Including videos or whatever else files is a bit tricky,
because different max versions behave differently.
You can't count on files being auto-found just by
placing them into same folder as Standalone app.
Using absolute path to the files is allways a safe bet.
Thank you! Hoping you can provide a bit more detail on your various points.
1. Yes, agreed, but do you believe that also applies to exported applications? It seems that the anti-piracy software is the issue, but I haven't tested it all that much
2. Newer versions were crashing when I ran the patch. I don't believe it used any externals at all, but it did make some use of presets for saving various state, which I believe were never ported forward from 4.5/4.6. I'm not sure why it is crashing, or how I would go about identifying the source of the issue since the application dies before I can read any error messages
3. Hoping I understand this correctly - you believe that a standalone, exported app from 4.5 would work on Mac up to Majave, but probably not after that, and it would need to run in 32 bit mode (I'm a bit concerned that this would have problems of its own given the amount of video we were loading into ram - I believe the version of OS X it was built on was 64 bit and thus could address more memory).
Finally, when you say 'using absolute path', do you mean that the path to the files themselves within the patch should use absolute path, e.g. /Users/Sam/Documents/Videos/... or something to that effect?
1. max 4.5 - actually 4.6.3 on mac could run till
10.11 el capitan more or less.
Any higher OS version - forget it, that's my experience.
Standalone would have more chance, any pace protection
will definitely fail.
Max 4 needs own interlok installation, and that does not work any more.
Max 6.1 would .
-----------------
With the path I mean using for example :
read "/Users/xy/Desktop/My Standalone Folder/example.mov"
rather than expecting that
read example.mov would work if one placed that file next to standalone.
There is a say that max standalone would find any file
placed in it's Contents/support/ folder.
But I would not use that.
If You need any help getting path into standalone or patch just post it.
in fact it is very simple, if it is a patch send path message to thispatcher.
if it is a standalone, message ; max sendapppath xxx will send path
to r xxx
-----------
You could post the patch to debug it, it does interest me
what is causing it to crash.
If You were able to load that large videos into max 4, than it should work as well
in max 7.
it is mostly the pace driver, but the free runtime is also not officially supported beyond 10.9., there is always a risk that minor stuff like quicktime, font size or so will stop working properly.
and of course it is 32 bit.
using a relative path to the patcher via thispatcher is a good idea, it makes you more independent from the enviroment.
When you say the patch will not open in recent versions of Max, what happens when you try this?
Thanks for all the help. I was able to go over to the studio today and experiment for a bit and I can say that exporting an application built on PowerPC will not produce anything that is compatible with newer versions of Mac OS. It has been a decade since I was a regular Max user and clearly my understanding of a lot of this stuff is rusty to say the least. The app that it produces is a PowerPC 32 bit binary and will not run. This is in contrast to the 10.6 runtime application, which does run (somewhat) on the newer OS.
I had limited time so I couldn't do much but next steps will be to attempt to export it as a collective and run that within the runtime environment with absolute paths to the video files, and then assuming that doesn't work, attempt to get it to run in Max 7.
When I say that the runtime 'somewhat' appears to work, I mean that I can open a patch, see messages on the console and hear some audio, however it doesn't appear to load Jitter. Any suggestions on using Jitter within the Runtime app on newer versions of the OS?
I believe I tried testing the patch on 5 and 8, I can't recall if I tried 6 or 7, so I will try those next and report back on the errors I receive. I can't post the patch on here as it wouldn't make sense without the various media files but we may be open to paying somebody to work through the kinks if I can't figure it out. Source, are you based in NYC by any chance?
Thanks again for the suggestions; I really appreciate it.
then why dont you build the application on the intel mac
Posting the patch without any media is also helpful.
One can see from loading messages what kind of audio or video files are used.
And , don't waste precious time trying to export anything from
max 4.5.
New Max versions use different video engines than
what used to be quicktime, one can select that in preferences too.
I am based in Europe, so I am afraid I can't just come by,
have a drink with You and have a look at the patch,
what I would really prefer to do.
But I am sure if You post the patch, somebody here will have a solution
for the problem in no time.
@Roman I can't build the application on an intel mac because I can't get 4.5/4.6 running on the latest version of the operating system. Maybe I will resort to booting of a drive with an older OS; I haven't ruled that out but I'm also not keen to do so.
@Source I'll see where I get tonight and will potentially post the patch if I don't have any luck. One question regarding 6 and above- I recall that when 5 was introduced, the 'preset' functionality from 4.x was not ported forward. Was that changed in 6 or 7? If not, then none of the orchestration that constitutes the bulk of the piece will work
Do You mean preset object ?
It still exists allright, but You probably mean that
stored data would not be recalled correctly if old patch would
run in new max version ?
I am not sure about that.
I remember having problems with data embedded in coll
when porting old patches, but don´t remember same thing about presets.
One could store preset data as files from old patch and see if that imports
into new version correctly.
Otherwise, one has to replace preset objects with different storage system.