Adobe After Effects for Small Displays

This is a simple public service announcement for Mac OSX After Effects users, or prospective Mac OSX After Effect users who are unsure if their small display – like, for example, the Macbook Air Mid-2013 model, which is 1366x768 – will be good enough for an After Effects 2017 install. The requirements stated on the Adobe website specify that a Windows display may be as small as 1280x1080, whereas the Mac OSX requirement is 1440x900.
Why Adobe insists on creating different requirements for these two platforms, I do not know and cannot fathom.
But I'm happy to report that yes, the display I am currently staring at, which is under the stated requirements for display size, is actually fine; you will be able to install and use Adobe After Effects 2017 if you have a 1366x768 display.
Perhaps you have landed here desperately searching for an answer regarding the adequacy or inadequacy of your display. As a friend of mine would say – after posting an absurdly silly Facebook post – I hope this helps.
And yes, the graphics card is still shit.

Cheetah3D Version 7 Is Now Available.

Well well well! Cheetah3D has an early adopter public beta out (v7pointblablabla).
It's available through the cheetah3d.com forums.
What stands out so far about this version (which I immediately paid for because I really like this software):

• It's still very affordable.
• The new booleans are way way way better.
• There's a new renderer called "Falcon", and this is what allows users to now include … wait for it … MOTION BLUR in their renders! You can tell I'm pretty excited about this, right? It looks gorgeous.
• Animated image textures (for texture, displacement, etc.) are now built in (previously this was only possible with a custom script – like the one I wrote … well, hacked). Various movie file "wrappers" can be used.
• A sculpting brush tool (needs to be expanded, but shows great promise).

 There are a lots of improvements and additions, but I've just scratched the surface. So far I haven't seen a lot of instability, and the compatibility with v6 seems to be pretty good.

Get it. Play with it. Make cool stuff with it.

Soundflower in Yosemite (and probably Mavericks and El Capitan)

Hey, Mac audio enthusiasts/podcasters/professionals! If you're a fan of Soundflower, the useful audio input/output kernel extension and its extra appendage utility, Soundflowerbed, you may have been frustrated by how everything got all messed up when you upgraded to Yosemite (or Mavericks, or El Capitan; this post is Yosemite-centric but probably applies to those other OS versions, too). After having to do this thrice I've decided that the world needed a clear explanation of how to get your Soundflower functionality back. Here's what you do.

First, install Soundflower after downloading with the installer at this url:

https://github.com/mattingalls/Soundflower/releases

The link looks like this:

Installing this should work fine.

Now download the old beta Soundflower installer from this url:

https://code.google.com/p/soundflower/downloads/list

The file is the top one:

 

You're going to use this to install ONLY the Soundflowerbed application (if you already have this installed, it may tell you that you're "upgrading"). Fire up this installer and when you get to this screen, hit "Continue":

 

Then, when you get to this screen, make sure you hit the "Customize" button:

 

 ... and do this to make sure you're only installing the Soundflowerbed utility:




This should give you the functionality you need. It worked for me.

An updated icon for Tex-Edit Plus

Here is a clean 512 pixel-tall icon for Tex-Edit Plus, the venerable script-able text editing application for OSX. Click on it, then right-click on the graphic to "save image as" a png with alpha locally.

OS 9 on Yosemite. Enables me to recover/convert old WriteNow documents, see what my AppleScript code looked like in the mid nineties, and pretend I'm not tethered to the "cloud".

Smile as R.A.D.

Rapid Application (ish) Development Using Smile

Back in the day, when I was a burgeoning AppleScript experimenter (at some point I became a “developer”, but it was a bumpy road), FaceSpan was the Rapid Application Development Environment I loved. It was fast and easy and powerful. Those days are gone. FaceSpan was dropped by its developer and by its rescuer-developer. XCode AppleScript Application Development became the de facto AppleScript development platform beyond the Script Editor (and indeed, it is very powerful). Other players (Hypercard, Supercard, Ultracard, MegaUltraCard [okay, I made a couple of those up] Runtime Revolution, QuicKeys [oh, man, did I have fun with that one], RealBasic/Studio, FutureBasic) fell by the wayside, for various reasons (although a few of them still have a following, at least, or some measure of commercial success).

I’d like to put in a good word for what seems to be a somewhat overlooked diamond-well-out-of-the-rough: Smile.

Why Smile?

Smile is known (at least) as a sophisticated AppleScript Script Editor developed by Satimage (satimage.fr), a french company whose software products SmileLab and Smile have been around since, oh, I don’t know, the Pleistocene perhaps.

Brass Tacks.

I admit it. Attempts to adopt AppleScript/Cocoa App Development have met with some success and some frustration. It’s not the fault of Apple (um ... no, it’s not. Wait ... no, it’s not). It’s because I spread myself very thin across many disciplines, of which software development is a very thin and spackled emulsion indeed. I have to re-learn. I have to dig up old snippets of code and manuals. I have to troll websites like the wonderful stackoverflow.com.

In short, I miss the direct and, dare I say it, intuitive flow of FaceSpan.

I’ve used Smile to create interface-rich dialogs (or even super simple dialogs, like the one which is a simple progress bar that can be used to offer feedback for my more complex or time-consuming scripts).

One of these dialogs, which I call ScanButton,

was originally just a button to activate the scanimage binary (http://www.sane-project.org/sane-frontends.html), but which soon (soon? yeah, soon) became a fairly sophisticated interface to scan, including previewing and pre-scan cropping.

I made this because I bought a scanner on craigslist which probably fell off a truck, was twenty bucks, and was lacking in consistent OSX-friendly software, especially for doing batches of scan sequences (among other things, I do traditional animation, you see). So I wrote my own, and utilized Smile’s dialog development.

My latest endeavor came about because I was messing around with ffmpeg (www.ffmpeg.org) to do fast conversions of movies (quicktime, windows media, avi, mpeg) for a job I was working on. Long story short (am I still typing?), I decided that I wanted to give the company I was working for a GUI-enhanced script to help with their approvals and deliveries. I wanted to do it quickly. I wanted it to be fun (yes, I find Smile “fun”).

Somewhere in the annals of Smile documentation there is a feature that allows you to wrap a scripted Smile dialog into its own app. Man, I can’t tell you how many times I tried to use that feature and had it blow up. It seemed buggy and unreliable. Whether or not it is buggy and unreliable is not the purpose of this article. But when developing this movie-converter dialog, I thought, why not just have the company download and install Smile, give them the dialog file (which is basically a double-clickable plugin) and have them use that? Is it possible, I wondered, to modify Smile so that the dialog acts just like a stand-alone-type thing? Basically, yes. AppleScript is at the heart of Smile; it’s one of the most beautifully complete AppleScript-powered applications out there. All you have to do is add some code into your dialog’s on prepare, on deactivated, and on delete handlers (and, if you like, add an additional handler, as I did), and you can make the dialog the main attraction and limit the user’s control over Smile (but if they want to do more Smile-y things, they can open Smile by itself and go to town).

The Code Snippets

on prepare theDialog

set prepared to true

modifySmileUI(theDialog)

end prepare

to modifySmileUI(thisMainDialog)

set menuKillList to {2, 4, 5, 9, 10, 11}

repeat with m in menuKillList

set visible of menu m to false

end repeat

--then get rid of specific items:

set visible of menu item "Clear Console" of menu 3 to false

set visible of menu item "Compare" of menu 3 to false

set visible of menu item "Output to Console" of menu 3 to false

set visible of menu item "Edit Mode" of menu 3 to false

set visible of menu item 18 of menu 3 to false--menu item "Go to line…"

set visible of menu item 19 of menu 3 to false--menu item ""

set visible of menu item "Find definition" of menu 3 to false

set visible of menu item "Enter selection" of menu 3 to false

set visible of menu item "Smile dictionary" of menu 1 to false

--set visible of menu item "Preferences..." of menu 1 to false--not accessible

close (every window whose name is not (name of thisMainDialog))

end modifySmileUI

on deactivated

thisDlg

--keeps Prefs from being opened :

--DANGER! Do NOT close the Prefs window; this will crash Smile in a bad way.

if ("Preferences" is in (name of windows)) then

set visible of window "Preferences" to false

set index of window "MovieForge" to 1 --hmm.

end if

end deactivated

on delete theDialog

continue delete theDialog

quit

end delete

The AppleScript code above represents everything I use to make my dialog feel more like a stand-alone. I comment out the “modifySmileUI(theDialog)” line in the first handler until the dialog is ready to be delivered. I also comment out the “quit” line in the last handler until the dialog is ready to ship. When the dialog is complete, I un-comment out these lines and the dialog is ready to be double-clicked by users who have no interest in the inner-workings of the dialog or Smile. They just want an interface to use for their workflow-enhancing pleasure.

What It Does.

Handler #1, on prepare, is what the dialog does as it is creating itself. When the modifySmileUI line “goes live” (gets un-commented), it calls the modifySmileUI handler which turns off all unnecessary menus and menu items in Smile, so that only the “Smile”, “Edit” and “Help” menus are visible.

The on deactivated handler, called when another window opens in front of the dialog, has some rather hack-y code that prevents (more or less) Smile’s Preferences from being opened. The idea here is that Smile’s Preference’s are accessible when using Smile, but not when using my dialog. As you can read in the comment, my first attempts at this, which actually sent a close window event to the Preferences window, caused Smile to crash hard, so I dispensed with this idea and used the “set visible to false” technique, which isn’t ideal (the interface is a little confusing for a split-second, and afterward, the main dialog floats in a sort of frontmost-but-not-frontmost limbo until you click on it), but it works.

Finally, the last handler, on delete, handles what happens when you close the dialog by quitting Smile completely, so that quitting the dialog quits the whole shebang, and no one is the wiser.

© 2014 Christopher R Green