After bumping into the performance ceiling using the 32 bit version of SA with large canvases at higher resolutions I fired up the 64bit version. However some of my manual paint brushes have "disappeared" from the menus (favorites bar and presets window) in the 64bit version. These appear to be older versions created around '06, but not all of those created around that time are affected. They do not show up in the usual places though they still reside in the original folder structure that worked in the 32bit version. Is this a "feature" of the 64bit version or is it something to do with the code structure of the older brushes? If so, is there a workaround to recreating or regaining the use of these brushes?
If you want to attach one or more of the presets you are having issues with here, i can take a look at them and comment further. Zip compress one or more of your old presets you are having issues with and attach them by using the upload files link in a reply post here. make sure you put them in a folder and then zip compress the folder so i get all of the old resource fork info in them.
And i'm going to assume you have both the 32 bit and 64 bit apps in the same Studio Artist 5 folder, so they are accessing the same Preset folder.
So what is going to work differently between the 2 versions (32 bit vs 64 bit) as far as presets go:
Any paint presets that use psd files for image brushes or image folder brushes are not going to be supported in the current 64 bit build. Also, any movie brushes are also not going to be supported in the current 64 bit build. Since we use 32 bit quicktime in V5 to work with psd files and quicktime movie files. And quicktime is not supported in the 64 bit build since quicktime is a 32 bit api. I would expect these particular presets to show up in the browser and just revert that part of the paint synth preset's settings to something like a computation brush as a default.
This same discussion for psd image brush and quicktime movie brush also applies to image and movie background textures in a paint preset.
Also, the 64 bit build cannot support any information contained in the preset's mac resource fork, only what is stored in the data fork. Older versions of Studio Artist used the resource fork in addition to the data fork to store preset information. So really old presets might be missing type ids and/or preview icons that were stored in the resource fork. Opening them in 32 bit V4 or V5 and then exporting a copy should fix that issue.
Really old PASeq presets might have issues opening in V4 or V5 unless they were opened and then saved in V3.5.
Older versions of Studio Artist opened loose presets that were not in a category folder by creating a special general folder it made for them. That does not happen in V4 or V5. So loose presets not in a category folder in V4 or V5 are not going to show up in the preset browser at all.
Thanks for the additional info and response. I think my problem seems to be related to the info in paragraph 6 - the resource fork issue. I believe several presets going back to a very early version of SA got a more current date at some point (probably due to my consolidation and renaming scheme). That appears to be the confusion on my part as regards to some of them being "newer" and not working. I've exported a few as a test and yep, they show up and work correctly. Appreciate the quick response and full explanation. If I come across any that don't port over I'll send them on for examination.
When we released V4 we auto-processed all of the old presets so that they would have the new iff sections that duplicated the old resource fork data in a V4 or greater preset's data fork. Since windows has no concept of a resource fork.
Unfortunately, apple has basically ignored their innovative mac resource fork support in recent years.
Not every old preset transferred properly to windows. So any of those were manually removed from the windows preset folder. Also not sure if the fully converted stuff ended up in all of the mac distributions, or just in windows ones.
The original way we stored path info to movie or image files was very quicktime specific (a data structure representing different parts of the location, as opposed to one simple pathname string), which doesn't move to 64 bit easily. so that was changed in V4 as well, but old presets that reference the image or movie file the old way might have issues if you tried to open them in the 64 bit app before converting them with the 32 bit app (by convert i mean open and then export).
I'm also finding the 64bit version a bit buggy (it could be something I am doing or my setup).
I'm running SA under 10.13.6 on an iMac with 32GB of RAM, a 1TB HD, a Wacom tablet and so forth. I'll work along for a period of time and then SA becomes unresponsive - the current brush I'm working with stops applying paint. I switch brushes, set the color palette to a specific color and try again. When I brush in the canvas again the color palette switches to the source image and I don't get paint on the canvas. Switching brushes multiple times results in the same repeated behavior. I hit the escape key (thinking maybe I launched an action or process by accident), get a dialog to quit the running process and hit "yes". The same non-responsive behavior persists. I even tried switching modes (for example to "warp" or dual paint) and SA remains unresponsive. However, I can save the canvas, quit and relaunch - things go back to normal for some unknown period of time. But, I have to reset my palettes and interface arrangement as well as the number of redos because these all default back to the original factory configuration. I'm assuming this could be related to a corrupted prefs file?
Not sure exactly where the prefs file is located so I am not able to trash it and restart to test that theory. Any help would be appreciated!
I'd suggest opening a tech support ticket for this issue. Then in the ticket, tell us very explicitly what you are doing, so that we can try and reproduce what you are doing here. So what resets you are using, how you are moving between them, what the status bar on the bottom right side says (it tells you if something is still running), etc.
It sounds like you are getting into a state where something is running that could potentially take a long time to finish and isn't easily stoppable prior to conclusion. So the interface seems un-responsive because you are trying to do something else while your original action is finishing up.