Archive for the ‘IT’ Category

Using Avid Unity Media Network on OS X 10.8+

May 24th, 2015

The last supported version of Mac OS X is 10.7.x with MN Client v5.5.5 (Mac only — the PC version 5.5.4 still works on Win7-64bit) — because 10.7.x is the last OS X version to support 32-bit extensions. You think! With the respective hack I already described for (now deprecated) versions of the ISIS client with OS X 10.9, you can take the equivalent steps to connect your Unity on OS X 10.8.x (haven’t tested with 10.9+, maybe this works, maybe it doesn’t), just pay attention that the Unity kexts and other files have slightly different names.

And another freebie.. even though Avid recommends using ATTO FC cards, this works with the original Mac FC cards (by LSI) too. The only drawback is the “limitation” to a 2Gb/s throughput, but that’s sufficient for most HD projects.

How to delight an engineer

July 29th, 2014

If you happen to work with engineers and they’re mostly unhappy with the way they’re being asked about potential projects, or if you’re an engineer in this very situation and your colleagues don’t seem to get it, here’s a simple how-to:

Step 1: Describe what the product or service is like when it’s finished, as precisely as you can, from A to Z. Put in the effort to sketch out the interface (if there is one), who does what in which particular order, who needs to know when something has happened, etc. Imagine how people will use it and what their expectations might be. Try to put yourself in every party’s shoes and walk through the whole thing. Think of legal constraints. Write everything down. (Use flowcharts whenever possible. Engineers love flowcharts.) Yep, that’s a lot, but believe me, it’s worth it.
Step 2: Define process boundaries. What is supposed to happen, what must not happen under any circumstance?
Step 3: Define development constraints. What is the budget? How much time is there to get this done?
Step 4: Have a meeting with the engineer(s) and give them all of what you have worked out so far, and they should be able to tell you what you need to know (can we do this in the quality proposed, considering all boundaries and constraints?) on the spot.

Bonus: How to delight engineers and non-engineers alike
Say Thank You, even if the answer you get is not what you were expecting.

Connecting to Avid ISIS 5000 on OS X 10.9

July 3rd, 2014

Though Avid doesn’t officially support this, it is entirely possible to connect your ISIS5000 < 4.6 using the respective ISIS client to your Mac on OS X 10.9, which currently only supports ISIS7000. Update: As of ISIS v4.6 this article is partially obsolete (see Avid KB).

To make it work, you need to have a Mac on which the ISIS client software that corresponds to your ISIS 5000 is installed. From there, copy the following items to a USB stick or network location, ideally you mimic the folder structure of your Mac HD in order to put everything in its appropriate place:

/Applications/AvidISIS (entire folder)
/Library/Application Support/Avid/AvidUnityISIS
/Library/StartupItems/AvidUnityISIS
/sbin/mount_AvidUnityISIS
(executable; use Cmd-Shift-G to go to folder)
/System/Library/Extensions/AvidUnityISIS.kext

Next, copy the files to your 10.9 machine’s system drive. You will need to enter admin credentials when modifying the /Library, /sbin, and /System folders.
Next, fire up Terminal to modify the permissions to certain files and folders, because those will very likely be “damaged” during the copying process off the original computer. You will need to enter your admin credentials when doing the following:

sudo chmod -R 0755 /System/Library/Extensions/AvidUnityISIS.kext
sudo chown -R root:wheel /System/Library/Extensions/AvidUnityISIS.kext

sudo chmod -R 0755 /sbin/mount_AvidUnityISIS
sudo chown -R root:wheel /sbin/mount_AvidUnityISIS

sudo chmod -R 0755 /Library/StartupItems/AvidUnityISIS
sudo chown -R root:wheel /Library/StartupItems/AvidUnityISIS

This will set the files and folders to the proper permissions. However, I strongly recommend verifying your permissions with Apple’s Disc Utility, because on one machine where I did this there was one admin user who couldn’t mount any of the ISIS workspaces (some error on the /Volumes folder), after repairing permissions everything was fine. And it is vital to perform these steps in this exact order, if you leave them out it won’t work.

Reboot your Mac, then you should be able to launch the ISIS client, and after properly setting up your connections you should be able to mount workspaces as usual.

Please keep in mind that this is a hack; Avid does not provide support for any problem that might occur because of this, neither do I. You’re doing this at your own risk. Make a backup copy before working on critical data or projects.

Angry nerds

January 2nd, 2012

Today the German version of Jonathan Zittrain‘s essay “The PC is dead” has been published (which he closes by saying we need more angry nerds), tempting me to comment on it in a lengthy post. Instead I recommend you to read it yourself.

My two cents: For platform owners such as Apple, Amazon, Google or Microsoft, the ‘art’ is to close the door only so much that the input-providing participants don’t feel uncomfortable squeezing through it, and keep providing stuff (apps and content), because the consuming participants will only start switching once they realize the restrictions applied lead to a perceived lack thereof. Angry nerds won’t fix it. Unless they invent a different thing that restarts the cycle.

Mac, Bootcamp, and the missing BOOTMGR

September 1st, 2011

Okay, lesson learned: Better not have two Bootcamp installation on one Mac system. Yes, it works when they’re on different (physical) drives. But then I decided to make two of the four drives a RAID, so I had to kill the old Win XP Bootcamp volume and the old Leopard volume (each on their own physical HD), because the Snow Leopard and Win 7 installations (both on the same HD) were working fine. And that’s when the soft brown substance hit the fan. Exactly.

Apparently, the Bootcamp EFI record only exists on one volume at a time, which in my case was one of the two that were merged to the RAID. On the next bootup, the Win 7 volume was not available. So what to do now?

Here’s a solution that worked for me:

  1. Get rEFIt and burn the image to a CD.
  2. Re-boot an launch the CD by holding down [option] or [c].
  3. Choose the Partition Tool (second to the left in the lower row).
  4. If it detects inconsistencies between the EFI and the MBR, have them be repaired.
  5. On the next boot, your Windows (Bootcamp) volume should show up. Try booting from it.
  6. If you’re getting the [BOOTMGR missing] error, continue reading. No errors: Congrats. Other errors: Good luck.
  7. Re-boot from your Win 7 installation DVD and navigate to the repair section.
  8. Choose “Start command prompt” (last item of the five).
  9. Enter bootrec /fixboot , hit Enter and wait for success.
  10. Enter bootrec /fixmbr , hit Enter and wait for success again.
  11. Reboot, start from the Win 7 partition and hope the error is gone. Yes? Congrats. No? Don’t worry, there’s one bullet left (as far as my experience goes).
  12. Re-boot again from the Win 7 installer DVD, go to Repair options and choose ”Auto-repair” (first menu item).
  13. That’s when I had it fixed. If you haven’t, I’m sorry I can currently do no more to help you. In some forums people have said that running the auto-repair routine multiple times eventually solved the issue, yet I can neither confirm nor deny it.

Quick Tips: Final Cut Pro 7 SmoothCam & Apple Color

July 28th, 2011

Not having posted for a long time, I thought a share some tips as a comeback teaser.

In various forums, people have reported problems with camera stabilization inside Final Cut Pro 7 using the plugin SmoothCam (which orginally comes from Shake, no pun intended), but not in Final Cut Pro 6. For comparison I ran some tests on both systems and came to the conclusion that FCP7’s SmoothCam does not work properly with interlaced footage no matter which codec you use. FCP6’s SmoothCam does the job with whatever kind of video.

Two more tips for Apple Color:

Always de-interlace when using Color, especially when working with Color FX. There are two ways to do this, one via the Clip Settings Tab and the other in the Color FX Tab. I haven’t compared whether they give different results but my guess is it’s not going to be that dramatic (we’re talking video ‘ere).

Last one: When migrating a Color project from Version 1.x (Final Cut Studio 2) to 1.5.x (Final Cut Studio 3) and you want to keep a copy of the old version, be careful to keep them in different folders. Thing is, when you rename the .colorproj bundle (it’s not a file, but a file package), Color will crash when opening the project (because he filenames inside the package don’t match). So you can either re-name the backup, open the current version, update & save-as the project and then re-rename the backup file, or just use different folders.

Idea: Speed Composing on a Music Collaboration Platform

June 12th, 2011

Here’s a proposal for something I can’t turn into reality myself:

There are a number of music collaboration platforms on the web already, but most of them don’t seem to be very productive, because all projects are open-end, there’s no deadline, no need to ship. Hence engagement soon drops after the initial euphoria. I think making music is more fun when it happens quickly and spontaneously, as well as under a time constraint, something you can see in the many remix contests that only allow participants to work on their remix for a few days or even a few hours.

So here’s the beef:
A collaborative music platform where there’s just a limited amount of time to finish a song. Not measured in real-word time, but in project-time. Huh? Very simple. A song has to be finished in, say, 12 hours. For instance, a guitarist starts a new project by uploading a riff. Someone downloads the music file and adds a bass part. The timespan until the new file is uploaded again will be added to this project, so when the bass player needs 90 minutes to contribute her part, there’s 10 hours 30 minutes left to finish the song. To spice it up even further, the whole thing does not happen in linear fashion, there can be multiple forks or branches per project. Again, huh? Well, say there are two bass players and each has a different idea (likely to happen), there will be two branches on each of which the project can be continued, each with its own timeline. Combine that with 3 different lyrics, 5 vocalists, one drummer, you might end up with 30 results based on the original part.

I’d be extremely happy to see someone turn this into reality. Got questions? Just drop me a line.

For beta or worse

July 24th, 2010

The other day, when I posted my insight on that one social network, one comment I got was “Tell that to the customer”.

Here’s what I responded:
“We’re all customers, aren’t we? And what do we appreciate more, trying to find an existing solution that’s already out there (a.k.a. “Check the FAQs” and “search for a tutorial”) or having someone take the time to (find out and) tell us what to do? Of course every customer prefers to have problems solved immediately, but that’s a different aspect of the same issue. Engineers and technicians used to be not very good at interaction with real people (yep, that’s a cliché), that’s why they preferred to keep track of every issue and include it in the manual or FAQ — or, ideally, they would solve the issue in a self-explaining way (not likely, but hey..). And -surprise!- people have not embraced studying manuals cover to cover, because it’s boring, techy stuff! Same problem as before.

Another point: An angry customer is just as good as a happy one, because he gives you two opportunities: You can solve his problem AND make him happy. That’s a reward for everyone involved, isn’t it? :)”

The reply to which was: ” ‘Of course every customer prefers to have problems solved immediately’ – You said it. And so everything else becomes void :-P Welcome to my world!”

This reminded me of one of my favourite drawings. And it’s quite interesting to consider it in the context of software.

20 years ago, handling computers was not very straightforward. You had to learn a set of commands to tell the machine what to do, which in itself was awkward enough to keep the majority of people away from it. Unless, of course, your computer’s brand contained a fruit. There was little convenience in using these gray boxes, and the once who used them were in majority expert enough to find workarounds in case something caused an error, like “Oh, this field requires only digits to be entered, and I entered letters, so it didn’t store them.”.

The first major shift happened when software became more accessible by graphical user interfaces (GUI). The upside for the software companies was they could sell more because there were more customers because of the improved convenience. The downside was that the more people used software, the less experienced they were. Thus manuals grew ever larger, and programmers had to implement more error handling and feedback mechanisms to tell the users what to do when the software didn’t deliver what the user thought it should.

The second major shift happened when computers became ubiquitous. Now software designers had to deal with the whole range of users from absolute newbies to experts who had been using their software since version 1.0. The analogy here is the VCR. Every household had at least one, but even in the 90s, when VCRs were sophisticated as they could be, only a small fraction of people would know how to set the time. It just wasn’t straightforward. It’s like comparing Microsoft to Apple to Linux. Every company or project has it’s own approach of how things should be, and some people favor one over another because it matches their expectation.

Nevertheless, it’s still software which has been made by people who do not always consider or who can’t anticipate every way a user will use their product. This is a given which also applies to custom designed software. People do not know everything they want their software to do, because they don’t care about what happens under the hood. What they do care about is the look of the GUI, and ideally, error handling and feedback functions that do not make them feel stupid.

Another thing that users in general have little concept of is “beta”, meaning “it should work, but there will be some glitches that we have to figure out yet”. Which is why most beta versions are free, because no one can expect you to pay for a product that doesn’t work. Or can they?

Zynga’s very popular game Farmville is labeled as beta ever since its release one year ago, spreading like wildfire with more than 70,000,000 players worldwide. Like other games, this one has a virtual currency allowing you to buy stuff in the game. One way to increase your amount of virtual currency is to buy it with real money. And what happens (quite predictably) is that people are confusing things: The game is free and still in beta, so you can’t expect it to work perfectly. But what you buy should be yours no matter what. This explosive combination detonates every once in a while. It’s technically okay when the game crashes, but not when items they bought disappear. But people do not distinguish between the two. Their posture is: “I pay for this, so I can expect it to work.” Which is not quite the case. What’s worse though is that they a) keep on playing no matter what, and b) they complain to the public, but not to Zynga. This is not changing anything, it’s just whining.

One more thing before I’m trying to wrap this up: Software design is also about fashion. It doesn’t matter if the latest trend or technique adds any value to your project, but you better brace yourself that your customer will ask for it — just because they can! They pick up something somewhere, and they will ask you just to look smart themselves, impress their peers, whatever.

So what do we make of all of this? You have to embrace a number of things:

  • Whatever approach you take, one size will not fit all. There will always be someone screwing up, and that’s when your phone rings.
  • Be careful about customer’s expectations. There’s a large shift as soon as money is involved.
  • People hardly call when everything is alright. That’s when you should call to ask for improvements and the like.
  • Expect your customers to be human, not tech experts. This also implies that they will react as humans do, meaning they will be angry when they call you in case something fails. That’s ok. You have the opportunity to solve their problem AND lighten their mood. Give them a hug.

Literacy

April 26th, 2010

Earlier this year a study was published stating that my fellow citizens, aka Krauts, rank their computer and Internet literacy relatively high, which came quite as a surprise for me. I think it was the highest figure of all European countries compared. Last week came out a study stating that the number one country in distribution of malware and bot infected computers is — no more bets taken — Germany.

Combine that with the result of another study concluding that Facebook users (in general) are very prone to spam and abusive clicking manipulation — never mind the fact that they accuse Facebook of ignoring privacy and personal rights, but on the other hand they just click shortlinks on somebody’s wall or blindly forward them, same goes for Twitter — and you get three conclusions:

  • There won’t be less spam in the near future.
  • Antivirus and Firewall software never compensate all user responsibility deficiencies.
  • Not getting an error message doesn’t mean you’re an expert.

Apple has a point

April 14th, 2010

Lately there was a lot of buzz going on because Apple has restricted the rules for app developers for the iPhone. They must not use cross-compilers to create their software but use the tools Apple gives them. This incurred some displeasure with the community, because many programmers were looking forward to use tools that would allow them to develop their apps platform-independent and compile them for Android, iPhone and what have you simultaneously.

But Apple’s policy makes perfect sense. Cross-compilers can induce errors in the executable app that can not be seen in the source code, because it’s an entirely different language. It’s like having a simaltaneous interpreter when you’re talking to someone whose language you’re not speaking. You don’t know if the interpreter is exactly saying what you were saying to him. No chance of verifying the output.

Also, programming software for Apple computers has meant starting from scratch ever since. You have to use an entirely different framework than on a PC. Never heard any complaints about that. Quite the opposite is true, many developers prefer Apple’s tools.

But the most important point is this: Apple knows perfectly well that if too many faulty apps are being released, this will not affect the programmers. Not at all. It will only affect Apple as a platform and as a brand. They have worked almost 30 years to build their reputation of “switch it on and it works straight away”, they will never ever put that to risk. Would you? Of course not.