Project organization

Leading into the new year, it’s time to take a fresh look at a perennial subject. Whether you work as a solo editor or part of a team, having a plan for organizing your projects – along with a workflow for moving media though your system – will lead to success in being able to find and restore material when needed at a future date. For a day-to-day workflow, I rely on five standard applications: Post Haste, Hedge, Better Rename, DiskCatalogMaker, and Kyno. I work on Macs, but there are Windows versions or alternatives for each.

Proper project organization. Regardless of your NLE, it’s a good idea to create a project “silo” for each job on your hard drive, RAID, or networked storage (NAS). That’s a main folder for the job, with subfolders for the edit project files, footage, audio, graphics, documents, exports, etc. I use Post Haste to create a new set of project folders for each new project.

Post Haste uses default or custom templates that can include Adobe project files. This provides a common starting point for each new project based on a template that I’ve created. Using this template, Post Haste generates a new project folder with common subfolders. A template Premiere Pro project file with my custom bin structure is contained within the Post Haste template. When each new set of folders is created, this Premiere file is also copied.

In order to track productions, each job is assigned a number, which becomes part of the name structure assigned within Post Haste. The same name is applied to the Premiere Pro project file. Typically, the master folder (and Premiere project) for a new job created through Post Haste will be labelled according to this schema: 9999_CLIENT_PROJECT_DATE.

Dealing with source footage, aka rushes or dailies. The first thing you have to deal with on a new project is the source media. Most of the location shoots for my projects come back to me with around 1TB of media for a day’s worth of filming. That’s often from two or three cameras, recorded in a variety of codecs at 4K/UHD resolution and 23.98fps. Someone on location (DIT, producer, DP, other) has copied the camera cards to working SSDs, which will be reused on later productions. Hedge is used to copy the cards, in order to provide checksum copy verification.

I receive those SSDs and not the camera cards. The first step is to copy that media “as is” into the source footage subfolder for that project on the editing RAID or NAS. Once my copy is complete, those same SSDs are separately copied “as is” via Hedge to one or more Western Digital or Seagate portable drives. Theoretically, this is for a deep archive, which hopefully will never be needed. Once we have at least two copies of the media, these working SSDs can be reformatted for the next production. The back-up drives should be stored in a safe location on-premises or better yet, offsite.

Since video cameras don’t use a standard folder structure on the cards, the next step is to reorganize the copied media in the footage folder according to date, camera, and roll. This means ripping media files out of their various camera subfolders. Within the footage folder, my subfolder hierarchy becomes shoot date (MMDDYY), then camera (A-CAM, B-CAM, etc), and then camera roll (A001, A002, etc). Media is located within the roll subfolder. Double-system audio recordings go into a SOUND folder for that date and follow this same hierarchy for sound rolls. When this reorganization is complete, I delete the leftover camera subfolders, such as Private, DCIM, etc.

It may be necessary to rename or append prefixes to file names in order to end up with completely unique file names within this project. That’s where Better Rename comes in. This is a Finder-level batch renaming tool. If a camera generates default names on a card, such as IMG_001, IMG_002 and so on, then renaming becomes essential. I try to preserve the original name in order to be able to trace the file back to back-up drives if I absolutely have to. Therefore, it’s best to append a prefix. I base this on project, date, camera, and roll. As an example, if IMG_001 was shot as part of the Bahamas project on December 20th, recorded by E-camera on roll seven, then the appended file would be named BAH1220E07_IMG_001.

Some camera codecs, like those used by drones and GoPros, are a beast for many NLEs to deal with. Proxy media is one way or you can transcode only the offending files. If you choose to transcode these files, then Compressor, Adobe Media Encoder, or Resolve are the best go-to applications. Transcode at the native file size and resolution into an optimized codec, like ProRes. Maintain log color spaces, because these optimized files become the new “camera” files in your edit. I will add separate folders for ORIG (camera original media) and PRORES (my transcoded, optimized files) within each camera roll folder. Only the ProRes media is to be imported into the NLE for editing.

Back-up! Do not proceed to GO! Now that you’ve spent all of this effort reorganizing, renaming, and transcoding media, you first want a back-up the files before starting to edit. I like to back up media to raw, removable, enterprise-grade HGST or Seagate hard drives. Over the years, I’ve accumulated a variety of drive sizes ranging from 2TB to now 8TB. Larger capacities are available, but 8TB is a cost-effective and manageable capacity. When placed into a Thunderbolt or USB drive dock, these function like any other local hard drive. 

When you’ve completed dealing with the media from the shoot, simply copy the whole job folder to a drive. You can store multiple projects on the same drive, depending on their capacity. This is an easy overnight process with most jobs, so it won’t impact your edit time. The point is to back up the newly organized version of your raw media. Once completed, you will have three copies of the source footage – the “as is” copy, the version on your RAID or NAS, and this back-up on the raw drive. After the project has been completed and delivered, load up the back-up drive and copy everything else from this job to that drive. This provides a “clone” of the complete job on both your RAID/NAS and the back-up drive.

In order to keep these back-up drives straight, you’ll need a catalog. At home, I’ve accumulated 12 drives thus far. At work we’ve accumulated over 200. I’ve found the easiest way to deal with this is an application called DiskCatalogMaker. It scans the drive and stores the file information in a catalog document. Each drive entry mimics what you see in the Finder, including folders, files, sizes, dates, and so on. The catalog document is searchable, which is why job numbers become important. It’s a good idea to periodically mount and spin up these drives to maintain reliability. Once a year is a minimum.

If you have sufficient capacity on your RAID or NAS, then you don’t want to immediately delete jobs and media when the work is done. In our case, once a job has been fully backed up, the job folder is moved into a BACKED UP folder on the NAS. This way we know when a job has been backed up, yet it is still easily retrieved should the client come back with revisions. Plus, you still have three total copies of the source media.

Other back-ups. I’ve talked a lot about backing up camera media, but what about other files? Generally files like graphics are supplied, so these are also backed up elsewhere. Plus they will get backed up on the raw drive when the job is done.

I also use Dropbox for interim back-ups of project files. Since a Premiere Pro project file is light and doesn’t carry media, it’s easy to back up in the cloud. At work, at the end of each day, each editor copies in-progress Premiere files to a company Dropbox folder. The idea is that in the event of some catastrophe, you could get your project back from Dropbox and then use the backed up camera drives to rebuild an edit. In addition, we also export and copy Resolve projects to Dropbox, as well as the DiskCatalogMaker catalog documents.

Whenever possible, audio stems and textless masters are exported for each completed job. These are stored with the final masters. Often it’s easier to make revisions using these elements, than to dive back into a complex job after it’s been deeply archived. Our NAS contains a separate top-level folder for all finished masters, in addition to the master subfolder within each project. When a production is done, the master file is copied into this other folder, resulting in two sets of the master files on the NAS. And by “master” I generally mean a final ProRes file along with a high-quality MP4 file. The MP4 is most often what the client will use as their “master,” since so much of our work these days is for the web. Therefore, both NAS locations hold a ProRes and an MP4. That’s in addition to the masters stored on the raw, back-up drive.

Final, Final revised, no really, this one is Final. Let’s address file naming conventions. Every editor knows the “danger” of calling something Final. Clients love to make changes until they no longer can. I work on projects that have running changes as adjustments are made for use in new presentations. Calling any of these “Final” never works. Broadcast commercials are usually assigned definitive ISCI codes, but that’s rarely the case with non-broadcast projects. The process that works for us is simply to use version numbers and dates. This makes sense and is what software developers use.

We use this convention: CLIENT_PROJECTNAME_VERSION_DATE_MODIFIER. As an example, if you are editing a McDonald’s Big Mac :60 commercial, then a final version might be labelled “MCD_Big Mac 60_v13_122620.” A slight change on that same day would become “MCD_Big Mac 60_v14_122620.” We use the “modifier” to designate variations from the norm. Our default master files are formatted as 1080p at 23.98 with stereo audio. So a variation exported as 4K/UHD or 720p or with a 5.1 surround mix would have the added suffix of “_4K” or “_720p” or “_51MIX.”

Some projects go through many updates and it’s often hard to know when a client (working remotely) considers a version truly done. They are supposed to tell you that, but they often just don’t. You sort of know, because the changes stop coming and a presentation deadline has been met. Whenever that happens, we export a ProRes master file plus high-quality MP4 files. The client may come back a week later with some revisions. Then, new ProRes and MP4 files are generated. Since version numbers are maintained, the ProRes master files will also have different version numbers and dates and, therefore, you can differentiate one from the other. Both variations may be valid and in use by the client.

Asset management. The last piece of software that comes in handy for us is Kyno. This is a lightweight asset management tool that we use to scan and find media on our NAS. Our method of organization makes it relatively easy to find things just by working in the Finder. However, if you are looking for that one piece of footage and need to be able to identify it visually, then that’s where Kyno is helpful. It’s like Adobe Bridge on steroids. One can organize and sort using the usual database tools, but it also has a very cool “drill down” feature. If you want to browse media within a folder without stepping through a series of subfolders, simply enable “drill down” and you can directly browse all media that’s contained therein. Kyno also features robust transcode and “send to” features designed with NLEs in mind. Prep media for an edit or create proxies? Simply use Kyno as an alternative to other options.

Hopefully this recap has provided some new workflow pointers for 2021. Good luck!

©2021 Oliver Peters

Drive – Postlab’s Virtual Storage Volume

Postlab is the only service designed for multi-editor, remote collaboration with Final Cut Pro X. It works whether you have a team collaborating on-premises within a facility or spread out at various locations around the globe. Since the initial launch, Hedge has also extended Postlab’s collaboration to Premiere Pro.

When using Postlab, projects containing Final Cut Pro X libraries or Premiere Pro project files are hosted on Hedge’s servers. But, the media lives on local drives or shared storage and not “in the cloud.” When editors work remotely, media needs to be transferred to them by way of “sneakernet,” High Tail, WeTransfer, or other methods.

Hedge has now solved that media issue with the introduction of Drive, a virtual storage volume for media, documents, and other files. Postlab users can utilize the original workflow and continue with local media – or they can expand remote capabilities with the addition of Drive storage. Since it functions much like DropBox, Drive can also be used by team members who aren’t actively engaged in editing. As a media volume, files on Drive are also accessible to Avid Media Composer and DaVinci Resolve editors.

Drive promises significantly better performance than a general business cloud service, because it has been fine-tuned for media. The ability to use Drive is included with each Postlab plan; but, storage costs are based on a flat rate per month for the amount of storage you need. Unlike other cloud services, there are no hidden egress charges for downloads. If you only want to use Drive as a single user, then Hedge’s Postlab Solo or Pro plan would be the place to start.

How Drive works

Once Drive storage has been added to an account, each team member simply needs to connect to Drive from the Postlab interface. This mounts a Drive volume on the desktop just like any local hard drive. In addition, a cache file is stored at a designated location. Hedge recommends using a fast SSD or RAID for this cache file. NAS or SAN network volumes cannot be used.

After the initial set up, the operation is similar to DropBox’s SmartSync function. When an editor adds media to the local Drive volume, that media is uploaded to Hedge’s cloud storage. It will then sync to all other editors’ Drive volumes. Initially those copies of the media are only virtual. The first time a file is played by a remote team member, it is streamed from the cloud server. As it streams, it is also being added the local Drive cache. Every file that has been fully played is now stored locally within the cache for faster access in the future.

Hedge feels that latency is as or more important than outright connection speed for a fluid editing experience. They recommend wired, rather than wi-fi, internet connections. However, I tested the system using wi-fi with office speeds of around 575Mbps down / 38Mbps up. This is a business connection and was fast enough to stream 720p MP4 and 1080p ProRes Proxy files with minimal hiccups on the initial streamed playback. Naturally, after it was locally cached, access was instantaneous.

From the editor’s point of view, virtual files still appear in the FCPX event browser as if local and the timeline is populated with clips. Files can also be imported or dragged in from Drive as if they are local. As you play the individual clips or the timeline from within FCPX or Premiere, the files become locally cached. All in all, the editing experience is very fluid.

In actual practice

The process works best with lightweight, low-res files and not large camera originals. That is possible, too, of course, but not very efficient. Drive and the Hedge servers support most common media files, but not a format like REDCODE raw. As before, each editor will need to have the same effects, LUTs, Motion templates, and fonts installed for proper collaboration.

I did run into a few issues, which may be related to the recent 10.4.9 Final Cut update. For example, the built-in proxy workflow is not very stable. I did get it to work. Original files were on a NAS volume (not Drive) and the generated proxies (H.264 or ProRes Proxy) were stored on the Drive volume of the main system. The remote editing system would only get the proxies, synced through Drive. In theory that should work, but it was hit or miss. When it worked, some LUTs, like the standard ARRI Log-C LUTs, were not applied on the remote system in proxy mode. Also the “used” range indicator lines for the event browser clips were present on the original system, but not the remote system. Other than these few quirks, everything was largely seamless.

My suggested workflow would be to generate editing proxies outside of the NLE and copy those to Drive. H.264 or ProRes Proxy with matching audio configurations to the original camera files work well. Treat these low-res files as original media and import them into Final Cut Pro X or Premiere Pro for editing. Once the edit is locked, go to the main system and transfer the final sequence to a local FCPX Library or Premiere Pro project for finishing. Relink that sequence to the original camera files for grading and delivery. Alternatively, you could export an FCPXML or XML file for a Resolve roundtrip.

One very important point to know is that the entire Postlab workflow is designed around team members staying logged into the account. This maintains the local caches. It’s OK to quit the Postlab application, plus eject and reconnect the Drive volume. However, if you log out, those local caches for editing files and Drive media will be flushed. The next time you log back in, connection to Drive will need to be re-established, Drive information must be synced again, and clips within FCPX or Premiere Pro will have to be relinked. So stay logged in for the best experience.

Additional features

Thanks to the Postlab interface, Drive offers features not available for regular hard drives. For example, any folder within Drive can be bookmarked in Postlab. Simply click on a Bookmark to directly open that folder. The Drop Off feature lets you generate a URL with an expiration date for any Bookmarked folder. Send that link to any non-team member, such as an outside contributor or client, and they will be able to upload additional media or other files to Drive. Once uploaded to Hedge’s servers, those files show up in Drive within the folder and will be synced to all team members.

Hedge offers even more features, including Mail Drop, designed for projects with too much media to efficiently upload. Ship Hedge a drive to copy dailies straight into their servers. Pick Up is another feature still in development. When updated, you will be able to select files on Drive, generate a Pick Up link, and send that to your client for download.

Editing with Drive and Postlab makes remote collaboration nearly like working on-site. The Hedge team is dedicated to expanding these capabilities with more services and broader NLE support. Given the state of post this year, these products are at the right time and place.

Check out this Soho Editors masterclass in collaboration using Postlab and Drive.

Originally written for FCP.co.

©2020 Oliver Peters

Apple Pivots – WWDC 2020

Monday saw Apple’s first virtual WWDC keynote presentation. This was a concise, detail-packed 108 minute webcast covering the range of operating system changes affecting all of Apple’s product lines. I shared my initial thoughts and reactions here and here. If you want some in-depth info, then John Gruber’s follow-up interview with Craig Federighi and Greg Joswiak of Apple is a good place to start. With the dust settling, I see three key takeaways from WWDC for Mac users.

Apple Silicon

Apple Silicon becomes the third processor transition for the Mac. Apple has been using Intel CPUs for 15 years. This shift moves Mac computers to the same CPU family as the mobile platforms. The new CPUs are based on Arm SoC (system on chip) technology. Arm originally stood for Acorn RISC Machine and is a technology developed by Arm Holdings PLC. They license the technology to other companies who are then free to develop their own chip designs. As far as we know, the Apple Arm chips will be manufactured in foundries owned by TSMC in Taiwan. While any hardware shift can be disconcerting, the good news is that Apple already has more than a decade-long track record with these chips, thanks to the iPhone and iPad. (Click here for more details on RISC versus CISC chip architectures.)

macOS software demos were ostensibly shown on a Mac with 16GB RAM and operating on an A12Z Bionic chip – the same CPU as in the current iPad Pro. That’s an 8-core, 64-bit processor with an integrated GPU. It also includes cores for the Neural Engine, which Apple uses for machine learning functions.

Apple is making available a developer transition kit (DTK) that includes a Mac mini in this configuration. This would imply that was the type of machine used for the keynote demo. It’s hard to know if that was really the case. Nevertheless, performance appeared good – notably with Final Cut Pro X showing three streams of 4K ProRes at full resolution. Not earth-shattering, but decent if that is actually the level of machine that was used. Federighi clarified in the Gruber interview that this DTK is only to get developers comfortable with the new chip, as well as the new OS version. It is not intended to represent a machine that is even close to what will eventually be shipped. Nor will the first shipping Apple Silicon chips in Macs be A12Z CPUs.

The reason to shift to Arm-based CPUs is the promise of better performance with a lower power consumption. Lower power also means less heat, which is great for phones and tablets. That’s also great for laptops, but less critical on desktop computers. This means overclocking is also a viable option. According to Apple, the transition to Apple Silicon will take two years. Presumably that means by the end of two years, all new Macs released going forward will use Arm-based CPUs.

Aside from the CPU itself, what about Thunderbolt and the GPU? The A12Z has an integrated graphics unit, just like the Intel chip. However, for horsepower Apple has been using AMD – and in years past, NVIDIA. Will the relationship with AMD continue or will Apple Silicon also cover the extra graphics grunt? Thunderbolt is technology licensed by Intel. Will that continue and will Apple be able to integrate Thunderbolt into its new Macs? The developer Mac mini does not include Thunderbolt 3 ports. Can we expect some type of new i/o format in these upcoming Macs, like USB 4, for example? (Click here for another concise hardware overview.)

macOS Big Sur – Apple dials it to 11

The second major reveal (for Mac users) was the next macOS after Catalina – Big Sur. This is the first OS designed natively for Arm-based Macs, but is coded to be compatible with Intel, too. It will also be out by the end of the year. Big Sur is listed as OS version 11.0, thus dropping the OS X (ten) product branding. A list of compatible Macs has been posted by Apple and quite a few users are already running a beta version of Big Sur on their current Intel Macs. According to anecdotes I’ve seen and heard, most indicate that it’s stable and the majority of applications (not all) work just fine.

Apple has navigated such transitions before – particularly from PowerPC to Intel. (The PowerPC used a RISC architecture.) They are making developer tools available (Universal 2) that will allow software companies to compile apps that run natively on both Intel and/or Arm platforms. In addition, Big Sur will include Rosetta 2, a technology designed to run Intel apps under native emulation. In some cases, Apple says that Rosetta 2 will actually convert some apps into native versions upon installation. Boot Camp appears to be gone, but virtualization of Linux was mentioned. This makes sense because some Linux distributions already will run on Arm processors. We’ll have to wait and see whether virtualization will also apply to Windows. Federighi did appear to say that directly booting into a different OS would not be possible.

Naturally, users want to know if their favorite application is going to be ready on day one. Apple has been working closely with Adobe and Microsoft to ensure that Creative Cloud and Office applications will run natively. Those two are biggies. If you can’t run Photoshop or Illustrator correctly, then you’ve lost the entire design community – photographers, designers, web developers, ad agencies, etc. Likewise, if Word, Excel, or Powerpoint don’t work, you’ve lost every business enterprise. Apologies to video editors, but those two segments are more important to Mac sales than all the video apps combined.

Will the operating systems merge?

Apple has said loudly and clearly that they don’t intend to merge macOS and iOS/iPadOS. Both the Mac and mobile businesses are very profitable and those products fulfill vastly different needs. It doesn’t make any business sense to mash them together in some way. You can’t run Big Sur on an iPad Pro nor can you run iPadOS 14 on a Mac. Yet, they are more than cousins under the hood. You will be able to run iOS/iPadOS applications, such as games, on an Arm-based Mac with Big Sur. This is determined by the developer, because they will retain the option to have some apps be iOS-only at the time the application is entered into the App Store.

Technology aside, the look, feel, style, and design language is now very close between these two operating system branches. Apple has brought back widgets to the Mac. You now have notification and control centers on all platforms that function in the same manner. The macOS Finder and iPad Files windows look similar to each other. Overall, the design language has been unified as typified by a return to more color and a common chiclet design to the icons. After all, nearly ever Apple product has a similar style with rounded corners, going back to the original 1984 Mac.

Are we close to actually having true macOS on an iPad Pro? Or a Mac with touch or Apple Pencil support? Probably not. I know a lot of Final Cut Pro X users have speculated about seeing “FCPX Lite” on the iPad, especially since we have Adobe’s Rush and LumaTouch’s LumaFusion. The speculation is that some stripped-down version of FCPX on the iPad should be a no-brainer. Unfortunately iPads lack a proper computer-style file system, standard i/o, and the ability to work with external storage. So, there are still reasons to optimize operating systems and applications differently for each hardware form factor. But a few years on – who knows?

Should you buy a Mac now?

If you need a Mac to get your work done and can’t wait, then by all means do so. Especially if you are a “pro” user requiring beefier hardware and performance. On the other hand, if you can hold off, you should probably wait until the first new machines are out in the wild. Then we’ll all have a better idea of price and performance. Apple still plans to release more Intel Macs within the next two years. The prevailing wisdom is that the current state of Apple’s A-series chips will dictate lower-end consumer Macs first. Obviously a new 12″ MacBook and the MacBook Air would be prime candidates. After that, possibly a Mac mini or even a smaller iMac.

If that in fact is what will happen, then high-end MacBook Pros, iMacs, iMac Pros, and the new Mac Pro will all continue running Intel processors until comparable (or better) Apple Silicon chips become available. Apple is more willing to shake things up than any other tech company. In spite of that, they have a pretty good track record of supporting existing products for quite a few years. For example, Big Sur is supposed to be compatible with MacBook Pros and Mac Pros going back to 2013. Even though the FCPX product launch was rough, FCP7 continued to work for many years after that through several OS updates.

I just don’t agree with people who grouse that Apple abandons its existing costumers whenever one of these changes happen. History simply does not bear that out. Change is always a challenge – more for some types of users than others. But we’ve been here before. This change shouldn’t cause too much hand-wringing, especially if Apple Silicon delivers on its promise.

Click here for a nice recap of some of the other announcements from WWDC.

©2020 Oliver Peters

The Missing Mac

High-end Mac users waited six years for Apple to release its successor to the cylindrical 2013 Mac Pro. That’s a unit that was derided by some and was ideal for others. Its unique shape earned the nickname of the “trash can.” Love it or hate it that Mac Pro lacked the ability to expand and grow with the times. Nevertheless, many are still in daily service and being used to crank out great wok.

The 2019 Mac Pro revitalized Apple’s tower configuration – dubbed the “cheese grater” design. If you want expandability, this one has it in spades. But at a premium price that puts it way above the cost of a decked out 2013 Mac Pro. Unfortunately for many users, this leaves a gap in the product line – both in features and in price range.

If you want a powerful Mac in the $3,000 – $5,000 range without a built-in display, then there is none. I really like the top-spec versions of the iMac and iMac Pro, but if I already own a display, would like to only use an Apple XDR, or want an LG, Dell, Asus, etc, then I’m stuck. Naturally one approach would be to buy a 16″ MacBook Pro and dock it to an external display, using the MacBook Pro as a second display or in the clamshell configuration. I’ve discussed that in various posts and it’s one way nimble editing shops like Trim in London tend to work.

Another option would be the Mac Mini, which is closest to the unit that best fits this void. It recently got a slight bump up in specs, but it’s missing 8-core CPU options and an advanced graphics card. The best 6-core configuration might actually be a serviceable computer, but I would imagine effects requiring GPU acceleration will be hampered by the Intel UHD 630 built-in graphics. The Mini does tick a lot of the boxes, including wi-fi, Bluetooth, four Thunderbolt 3/USB-C ports, HDMI 2.0, two USB 3.0 ports, plus Ethernet and headphone jacks.

I’ve tested both the previous Mac Mini iteration (with and w/o eGPU) and the latest 16″ MacBook Pro. Both were capable Macs, but the 16″ truly shines. I find it hard to believe that Apple couldn’t have created a Mac Mini with the same electronics as the loaded 16″ MacBook Pro. After all, once you remove the better speaker system, keyboard, and battery from the lower case of the laptop, you have about the same amount of “guts” as that of the Mac Mini. I think you could make the same calculation with the iMac electronics. Even if the Mini case needed to be a bit taller, I don’t see why this wouldn’t be technically possible.

Here’s a hypothetical Mac Mini spec (similar to the MacBook Pro) that could be a true sweet spot:

  • 2.4GHz 8-core, 9th-generation Intel Core i9 processor (or faster)
  • 64GB 2666MHz DD4 memory
  • AMD Radeon Pro 5600M GPU with 8GB HBM2 memory
  • 1TB SSD storage (or higher – up to 8TB)
  • 10 Gigabit Ethernet

Such a configuration would likely be in the range of $3,000 – $5,000 based on the BTO options of the current Mini, iMac, and MacBook Pro. Of course, if you bump the internal SSD from 1TB to the higher capacities, the total price will go up. In my opinion, it should be easy for Apple to supply such a version without significant re-engineering. I recognize that if you went with a Xeon-based configuration, like the iMac Pros, then the task would be a bit more challenging, in part due to power demands and airflow. Naturally, an even higher-spec’ed Mac like this in the $5,000 – $10,000 range would also be appealing, but that would likely be a bridge too far for Apple.

What I ultimately want is a reasonably powerful Mac without being forced to also purchase an Apple display as this isn’t always the best option. But I want that without spending as much as on a car to get there. I understand that such a unit wouldn’t have the ability to add more cards, but then neither do the iMacs and MacBook Pros. So I really don’t see this as a huge issue. I feel that this configuration would be an instant success with many editors. Plug in the display and storage of your choice and Bob’s your uncle.

I’m not optimistic. Maybe Apple has run the calculation that such a version would rob sales from the 2019 Mac Pro or iMac Pros. Or maybe they simply view the Mini as fitting into a narrow range of server and home computing use cases. Whatever the reason, it seems clear to me that there is a huge gap in the product line that could be served by a Mac Mini with specs such as these.

On the other hand, Apple’s virtual WWDC is just around the corner, so we can always hope!

©2020 Oliver Peters

It’s great… Until it isn’t

No, that picture at the top isn’t a map of Covid-19 hotspots. It’s the map of US users affected by this week’s Adobe sign-in outage. This past Wednesday (May 27th) affected users across all of Adobe’s various cloud products were unable to sign into their accounts – locking them out of using any installed Adobe products. But not every user – only those who needed to sign in to enable their applications.

Adobe products, like Creative Cloud, are paid on a monthly or prorated annual basis. You sign in one time to activate the account on that device and you are good to go until renewal time, as long as you stay signed into the cloud license manager application. In theory, you don’t need to be continually connected to the internet for the applications to function. However, once a month Adobe’s servers are pinged and you may be prompted to sign in again. So if Wednesday was your machine’s day to “phone home,” you haven’t used the apps in a while, or if you were signing in after having previously signed out, then your Adobe cloud manager application was unable to connect to the server and activate (or reactive) your software product(s). Just like that, a day of billable time flushed away.

Before you grab the torches and pitchforks, it may be useful to revisit the pros and cons of the various software licensing models.

Subscription

Quite a few companies have adopted the subscription – aka software as a service or SaaS – model. The argument is that you never actually own any software, regardless of the company or the application (read any EULA). Rather, you pay for the right to use it over a specified period of time – monthly, annually, or perpetually. Adobe decided to go all-in on subscription plans, arguing that the upfront costs were cheaper for the user, the plans offered a better ROI with access to many more Adobe products, and that this provided a predictable revenue stream to fuel more frequent product updates.

Generally, these points have been realized and the system works rather well most of the time. Yes, you can argue that over time you pay more for your CC subscription than in the old CS days (assuming you skipped a few CS updates). But if you are an active facility, production company, or independent contractor, then it’s a small monthly business expense, just like your internet or electric bill, which is easily absorbed against the work you are bringing in. The software cost has shifted from cap-ex to op-ex.

That is all true, unless you have no revenue coming in or are merely working with media as a hobby. In addition, once you stop subscribing, all past project files – whether that’s Premiere Pro, Lightroom, Photoshop, In Design, etc – can no longer be opened until you renew.

Unfortunately, when you hit a day like Wednesday, all rational arguments go out the window.

The App Store model

If you are a Final Cut Pro X user, then Wednesday might have stirred the urge to say, “I told you so.” I get that. The App Store method of purchasing/installing/updating software works well. You only have to sign in for new purchases, new Mac installations, and occasionally for updates.

However, don’t be smug. Certain applications that Apple sees as a service, like News, occasionally prompt you to sign in with your Apple ID again before you can use that software. This is true even if you haven’t subscribed to any paid magazines or newspapers. In a scenario such as Adobe’s Wednesday outage, I can image that you would be just as locked out. Not necessarily from your creative apps, like FCPX, but rather certain software/services, such as News, iTunes, Music, etc. As someone who uses my iCloud e-mail account quite a lot through web browsers, I can’t count the number of times access has been hampered.

License managers

Similar to the App Store or Adobe Creative Cloud, some companies use license manager software that’s installed onto your machine. This is a common method for plug-in developers, such as FxFactory and Waves. It’s a way of centralizing the installation and authorization of that software.

FxFactory follows the App Store approach and includes purchasing and update features. Others, like Waves and Avid Link, are designed to activate and/or move licenses between machines, based on the company’s stored, online database of serial numbers. You typically do not need to stay online or be signed in unless making changes or updates, or your system has changed in some way, like a new OS installation. These work well, but aren’t bulletproof – as many Media Composer editors can attest.

Activation codes

One of the oldest methods is simply to provide the user with a serial number/activation code. Install the software and activate the license with the supplied code number. If you need to move the software to a different machine, then you will typically have to deactivate that application on the first machine and activate it again on the second machine. You only have to be connected to the company’s servers during these activation times. Some companies also offer offline methods for activation in the event you don’t have internet access.

Seems simple, right? Well, not necessarily. First of all, if you have a lot of software that uses this method, that’s a lot of serial numbers you will have to keep track of. Second, some companies only give you a limited number of times you can deactivate and reactivate the software. If that’s the case, you can’t really move the license back and forth between two machines every other week. If your motherboard dies with the software activated, you are likely going to have to jump through hoops to get the company to deactivate the number on their server in order to be able to activate it again on the repaired machine. That’s because the new motherboard IDs it as a completely different machine. Finally, even some of these companies require you to occasionally sign in or reactivate the software in order for you to continue being able to use it.

Hardware license key

Ah, the “dongle.” When Avid switched to software licensing, many Media Composer editors approached it with the attitude of “from my cold, dead hands.” And so, Avid still maintains hardware licensing for many Avid systems. Likewise, Blackmagic Design has also shipped dongles for DaVinci Resolve and Fusion. iLok devices, common among Pro Tools users, are another variant of this. Dongles, which are actually USB hardware keys, make it simple to move authorization between machines. That’s useful if you maintain a fleet of rental systems. No internet required. Just a USB port.

Unfortunately, dongles are subject to forgetfulness, loss, breakage, theft, and even counterfeiting. A friend reminded me that when Avid Symphony first came out and cost $100K for a system, dongle theft was a very real issue. That’s likely less the case now, because software is so cheap by comparison. I do know of film schools that extended their Media Composer dongles on a USB extension cable and then strung it to the inside of their Mac Pro. Lock the case for viable theft prevention.

Free

The Holy Grail – right? Or so many users believe. It’s the model Blackmagic uses for the standard versions of Resolve and Fusion. Many plug-in developers use the free model on a few plug-ins just to get you interested in their other paid products. Of course, the ease of making Motion Templates for Final Cut Pro X has create a homegrown hobbyist/developer market of free or extremely cheap effects and graphics templates.

Even though some commercial software is free, you are only granted the right to use it, not ownership. Often in exact for user data so that you can be marketed to in the future. As a business plan for a commercial developer, this model is only sustainable because of other revenue, like hardware sales. And in practice, even the Mac App Store model, with its “buy once” policy, is close to free when you own and personally control a number of Macs.

There are pros and cons to all of these models. They all work well until they don’t. When there’s a hiccup, roll with the punches, or contact support if it’s appropriate. With some luck, there will be a speedy resolution and you’ll be back up and running in no time.

©2020 Oliver Peters