Porting old Studio Artist V5 to V5.5 on the mac has been quite an adventure. For many reasons, but today we're going to focus one specific little area.
All versions of Studio Artist prior to V5.5 were internally based on apple's quicktime api. Which in their infinite wisdom they gutted with a knife and killed off when they decided to totally bail on 32 bit applications and 32 bit code apis for developers.
But why didn't they just port the quicktime api to 64 bit people oftentimes ask me. I haven't worked at apple for over 20 years, so we can only speculate. I have however seen the actual quicktime code back in the old days, and it was all based on old style GWorlds (GWorlds are messy). So yeah, i can understand why they wanted to get rid of that.
So why didn't they rewrite the inner workings, and then attach that to a new set of higher level api calls that closely mirrored the structure of the old ones i then get asked? To make porting people's old code that used the old quicktime api calls easy when they wanted to port it to 64 bit. Yeah, real good question.
Instead, they told everyone to switch to a separate api called QtKit that was 64 bit. Of course QtKit seemed pretty half-baked, missing important features, and was then unceremoniously dropped later on when they killed off the quicktime api. So good thing we didn't waste our time doing that.
Instead they switched over to something totally new called AVFrameworks. With no C++ api calls. Instead, every C++ developer could go try to implement their own C++ api headers that tie into the objective c code AVFrameworks lets you tap into. Because why would apple tell one apple engineer to do this work for all their developers when they can instead just make every 3rd party developer do it themselves. This is a repeating pattern occuring over and over again int he apple - apple developer relationship, or i wouldn't be so bent out of shape about it.
But of course apple actively tries to discourage C++ development on their platforms these days. In subtle and not so subtle ways. Even though none of their historical long time developers used it when they started that push. They want you to use either objective c and Cocoa, or Swift these days. Probably because both options essentially lock you into the apple platform with no real way to escape.
So we see what is a re-occuring theme here, screw you existing developers, apple knows best. We also see another re-occuring theme here, apple loves to kill off the past. As in all of your previous work. Apple wants to torpedo it, make it non-functional, pretend it never even existed. And they do that over and over and over again.
Gee, that sucks for developers you may be thinking, but i'm a user, surely apple loves their users.
Does apple really love their digital media content developers and digital artist users? Apparently not. because when they killed off the quicktime api, they also killed off most of your old movie brushes (and all of your other old quicktime based media content).
Now how they did this was one giant fuck you to all of their old time digital media content users that used quicktime to archive their work. Because many of those people used quicktime codecs that are now no longer supported on apple's platform.
A classic example of this is the old quicktime animation codec. It allowed for lossless compression at the highest quality settings along with support for an additional embedded alpha channel. All of our old factory movie brushes used this codec for exactly those reasons.
And if you made movie brushes you used in Studio Artist, you probably did that as well.
You probably also archived final work, both from Studio Artist as well as other software products in various quicktime codec formats that are not longer supported on the mac platform. No longer supported beyond Mojave. These files are files of nothing on Catalina, Big Sur, Beautiful Fremont (our pick for the next mac os name).
Now i can totally understand why they might not want the old animation codec code to dirty their spanky new GPU engine for live streaming video. Totally get it. But i find it odd that the company with one of the world's largest capitalizations, the company that had no trouble trotting out Rosetta 2 emulation to run intel code in emulation on ARM Risc chips, i find it odd that adding import for a run length encoder movie codec was too technically advanced to implement.
Or perhaps they just didn't care.
That last answer is the correct one. They didn't care about the over 20 years of quicktime encoded source mater, final projects, movie brushes, etc that their long time users had archived. It just never even existed.
So, what is the poor digital artist that used macs forever to do with all of that old quicktime api encoded material. Obviously you need to keep a mac running Mojave around forever (good luck on that one) to even read it. Because if you want to convert it into something that is readable on Catalina or later, you are going to need it.
Apple's deceptively named Quicktime Player app (deceptive because it does not use the quicktime api, nor read most of the previously acceptable quicktime file api codec formats) will open those old no longer supported quicktime codec encoded files on Mojave (not on Catalina, Big Sur, Beautiful Fremont, etc). It brings up a dialog saying it is 'converting' them. And then you can save those 'converted' files.
It saves them as H264 mov files (you don't have a choice in the matter). If they had an alpha channel, that is magically missing now. And if the files were lossless before, they sure as shit aren't now (they look pretty horrendous). You might have better luck with the old Quicktime Player 7 Pro app. Which was actually a really great as a swiss army knife utility for working with quicktime movie files, and allowed for a full range of export options (unlike the brain dead newer Quicktime Player app they ship these days).
So, if you have old movie brush files you used in Studio Artist that didn't come with our factory set of presets, you are going to have to convert them. We converted the old factory ones for you, and they are in the Brush folder of Studio Artist V5.5.
Now if you want to use those converted movie brushes on windows, you are going to have to do a second file conversion (thanks apple?). Because the H264 mov files that apple exports on Mojave are not going to work both in the Windows Media Player and in Studio Artist V5.5 on windows on most (bizarrely not all) windows computers.
Fortunately, you have Studio Artist V5.5 to the rescue. Because if you just pass them through Studio Artist V5.5 outputting to H264, then they will work on all windows 64 bit win 10 computers. In the Windows Media Player, as previews in the windows finder, and in Studio Artist V5.5 on windows.
But now we get to another apple gotcha. Because many of you might already have a Studio Artist 5 folder in your Applications folder on Catalina or Big Sur (Studio Artist V5 64 bit runs on both). And any old presets that reference those old factory movie brushes reference them with a pathname like this
"/Applications/Studio Artist™ 5/Brush/Movie Brushes/WackBrush1"
Now Studio Artist is smart enough to search in your local Brush folder located next to your running Studio Artist application if it can't find the pathname file reference for the movie brush.
But of course if you have both a Studio Artist 5 folder and a Studio Artist 5.5 folder in Applications, then Studio Artist V5.5 is going to find the old totally valid movie brush pathname file reference, and try read in the old movie brush file that can no longer be read on Catalina or Big Sur. And you wonder why things aren't working until you figure this out. It's very annoying.
If you add an extra letter to the name of the old Studio Artist 5 folder name, that will prevent this from happening.
Studio Artist is smart about searching for any image or movie brush files inside of the local Brush folder if the original file reference is no longer valid.
But of course we are not done with apple gotchas.
Because for some weird reason, when Studio Artist V5.5 tries to open totally valid movie files that are stored inside of our Brush folder inside of the Studio Artist folder (which is inside of the Applications folder), we can't open them on Big Sur.
But if you either move the Studio Artist folder somewhere else (like in your Documents folder), then the movie files open fine. Or if you keep the Studio Artist folder inside of Applications, and instead reference a movie brush somewhere else in your filesystem, they open fine. This is true for both movie brushes and movies you want to open as the source.
Now this is a conundrum, since we store Studio Artist assets like Brush assets inside of the Studio Artist folder. Rather than installing them in weird hidden locations (like /users/yourname/Library/ , which is a hidden folder for normal users that can't even be seen in the Finder unless you use special tricks).
I think we're going to add a preference option to retarget your brush folder to ultimately resolve this. But it's still not ideal, because i would really prefer to keep the drag and drop installer rather than move to some more elaborate installer that dumps stuff at various places on your hard disk.
My take on all of this is that movies used to be awesome on the mac, and now the whole movie thing is one giant mess on the mac. Things work differently from os version to os version, essential utility tools that were freely available on the platform are just abandoned, all of your old work is rendered useless.
And the crippling of essential file system file access features is also just one giant mess. I view it through the lens of apple slowly turning the mac computer into just another locked down information appliance. A computer is an engine for the mind. An information appliance is a purposely crippled widget, primarily designed to suck money out of you while also providing some additional value to make the spending of money on it seem useful. Useful for some tasks (web browsing, watching a video, reading a kindle book, etc), but generally restricted and limiting in so many ways.
The new 'security' features are ridiculous. A user specifically navigates apple's own standard file dialog to access a file in some specific part of the file system, and then a parental warning message comes up asking you if you really want to access a file in Documents? The user just specified that by working with apple's standard file dialog to get there? If they didn't want to access a file there, they would not have used said standard file dialog to navigate there in the first place. The endless nagging is tiring pretty quickly.
And of course the nagging doesn't stop there. Because every day your essential Mojave system you absolutely need to read all those old file formats no longer supported will try to trick you into updating to a newer os version that will kill off the ability to read those old files. Because apple doesn't care about you or your precious old work. They would much rather prefer that you buy all new applications from their app store so they get a 30% cut of the revenue, and that you do that every new os release. Preferably using their apple credit card, so they get an additional cut.
It's a sad statement on what used to be a great platform (indeed used to be the best) for digital artists and digital media developers, both users and developers of those tools. I can no longer say that is true.
Why would anyone ever depend on an apple proprietary file format every again. Or an apple proprietary code api for that matter.
So there is a view into the giant mess that apple has rendered unto digital artists on their platform. Meanwhile windows keeps looking better and better, which is something i thought i would never say.
It's really a shame, because they did a fabulous job with the new M1 ARM Risc chips. But their software, ouch. And their attitude, double ouch.
I think we're going to be moving to support MNG file format for movie brushes in the future as an alternative to the existing support we provide. No dependence on apple computer, so they can't muck it up somehow next year when the new Beautiful Fremont mac os hits the ground running.
We support image folder brushes, so there is a totally acceptable alternative way to get there (lossless compression and alpha). But there are advantages to having one file rather than a whole folder sometimes for things like a movie brush. MNG is an open source container file format for PNG files, so it's a great solution for lossless movies that also fully supports alpha.
No comments:
Post a Comment