iShowU Studio Quickstart videos are now online

I spent some quality time with Studio yesterday to produce five quick start videos for iShowU Studio. These are aimed at introducing Studio to people new to the app and video editing in general.

These videos are now online, available both in our video section and also as a playlist on YouTube.  Here’s a brief synopsis of each:

  1. Introduction, what Studio “is” and a quick tour of the UI. I also covered basic insertion of shapes.
  2. Basic Editing, how to select objects, multiple selection, lasso dragging, delete, trim and region cut
  3. Properties & Visualization, modifying the look of objects and using mouse & keyboard visualizers
  4. Advanced Editing, introduction to Pan/Zoom & Freeze Frame, an also freezing using an audio insert. Examples of all of these are included in the video.
  5. Sharing, how to share as a QuickTime file, sharing to YouTube and also authentication with YouTube via oAuth.

Probably the hardest part (for me) was making these videos short. As a precursor to this effort I spent some time planning a table of contents of all features of Studio. If I were to keep the videos at about 4m each I think I ended up with about 17 videos in total! When you pause and write down all the little things Studio can do, you end up with a lot of material to cover!

As always, I’m keen for further suggestions for more video.  I feel “aware” that these cover the basis, and those users who have more experience may be interested in more complex workflows. Fire suggestions my way!

I feel like I’m getting a handle on how to produce them reasonably quickly. These five took me about 8-10 hours and that time includes script writing, proofing, production, encoding, uploading and blog posts.

I’ll probably make a post at some point about the workflow I’m currently using (it’s essentially: all audio first, make the video fit). I’m finding that doing the script first, audio and then video means I have very very little rework (if any, in fact).

Don’t leave all the loot for Neil!

It’s me again :)

I thought I’d do something a little different (you know, because I can’t spend all day coding, right?) and run a competition involving iShowU Studio. The idea is simple: You create a awesome looking small video showing how you make use of Studio and we give away some neat prizes including an Apple TV, iPod shuffle and iTunes vouchers.

Full details are over on here on the main website. You can register from that page and we’ll send an confirmation email a few minutes later along with instructions and super interesting things like terms & conditions :)

I’m keen to see what people come up with! I’ve been talking to a few people recently and it’s been exciting to see what people are doing with iShowU. I’m hoping this competition shows up some more projects that people are working on, and I’m looking forward to the response!

Why are still reading? Go over to the competition page and register now!

Layout text using Cocoa? You might want to rethink that!

I’ve recently been refactoring the text implementation in iShowU Studio.  Previously I had used Cocoa’s built in NSString additions (drawAtPoint: etc), which appeared to work pretty well apart from some minor hiccups trying to get the text vertically centred.

In the initial release of Studio I got around the vertical problem by munging the values. The font was fixed, so I could get away with that.

Version 1.0.4 of Studio introduced the ability to change the font. Things started to go … quite … wrong.  Cocoa’s idea of what constitutes a text rectangle (aka: bounding box) is weird, and often just downright plain wrong.  Here’s an example:

Not what the doctor ordered. Very incorrect bounding boxes.

Not what the doctor ordered. Very incorrect bounding boxes.

The red line represents what Cocoas NSString additions think the bounding box is. Notice it’s too tall. That’d result in the text being too low when vertically centred. Sometimes it’s right. Sometimes it’s not.

The blue box is what NSLayoutManager thinks. Um, I’m not a rocket scientist, but I’m pretty sure that text is not going to fit in there.  What’s worse is that sometimes each of the methods above gets it right, sometimes not. And they are both inconsistent. Pretty much completely useless if you want to  present correctly vertically centred text. And before you ask, because I just know it’s on the tip of your tongue, yes I did set the NSTypesetter behaviour to NSTypesetterBehavior_10_2_WithCompatibility.

In short, unless I’m doing something stupid (always possible) various fonts yield very very different bounding boxes. Nothing is consistent, so if you’re going to try to layout this text vertically centred, good luck with that.

CoreText – no so hard after all

I scratched my head over this one for a couple of days, pondering what to do while I worked on some other code. Enter, CoreText.

Turns out it actually works. The bounding boxes returned are way more sane. Here’s the same text, with the same font, but rendered using CoreText:

Look at that! It's a sensible bounding box!

Look at that! It’s a sensible bounding box!

I must give credit to Jjgod Jiang for his slides on text layout. With that I was able to create a simple class that’d a) perform the right layout and b) provide decent bounding boxes that were consistent across all fonts.

So, if you find yourself struggling to perform layout with the Cocoa NSFont/NSLayoutManager classes, or if you want to discover correct bounding boxes for arbitrary (and possibly multi line) strings, turn to CoreText. It’s simple enough to use, and it actually works.

iShowU Studio receives improvements to general editing

Hi Everyone!

As I’ve been using Studio myself, I’ve come across a few bugs (lets call the fixes improvements to general editing shall we?). The most obvious this week was some strange behaviour with freeze-frame. I couldn’t freeze the end of a segment. Nothing would happen. Huh? … And when I did finally create the frame I wanted I couldn’t resize it to take up the available free space. Grr.

These issues are now fixed, with a few other bug fixes thrown in for good measure. Now Studio is behaving far more sensibly when doing freeze operations. Yay!

Don’t loose the plot

One of our customers, Alain Desson also kindly emailed me a nicely detailed report of odd Autosave behaviour. Because of this, I was able to quickly find and fix the problem.  Good thing too, since this particular bug could have resulted in lost files!  Eek! Thanks Alain!

If you’re curious, here is what would happen (all in the past now, a great reason to update!):

  1. You’d schedule a recording using the timer.
  2. Recording would proceed, but during the recording you would click on something else, thus iShowU Studio would no longer be the focused/active app.
  3. Recording would complete, and iShowU Studio would bring up the new doc in the background.
  4. 15s later – Studio would decide to delete the saved document from disk. Not good.

Note that this only happened if (2) was true. Sometimes AppKit is downright weird. This ended up being a one line fix, and now works just fine.

Ponder Ponder

It’s not all bug fixing here. I’ve been working on a rewrite of the properties panel, I’m thinking about how to introduce nice transitions, and I’m pondering how I’ll go about moving all the assets from their projects into a general “per volume” storage vault.

On with the code!

I completely forgot to talk about lockable segments and partial freeze-frame

In my post the other day about the new features in iShowU Studio, I completely forgot to mention the new locking feature.

Lockable Segments

Each segment can now be locked. This prevents the segment from being moved, scaled or rotated. It also prevents the segment being split, or deleted or region cut. You can still change it’s properties, it’s just “locked” in the scene.

To lock a segment right click on it either in the timeline or the scene, and choose the “Lock Segment” from the menu.

Quite useful for backgrounds that you want to span the entire scene. Or for inserting a completed audio track and then working the video around that track. Locking the audio track means you can perform cut/slice/cut operations at will, without worrying about what is selected. It makes editing quicker.

Freeze Selected Objects

In addition, I added a freeze frame for selected objects. So while you can still freeze over the entire project, you can now also select just one/some segments and freeze just those. That’s great for expanding out short bits of video that you want to be a little longer.

To freeze just selected objects, you first have to select some. So… select some segments in the timeline. Then go to the Edit menu. There’s a new item there named “Add freeze frame on selected segments“.  Done!

Note: remember to have the playhead positioned where you want the split to occur. If the playhead is not over any of your selected segments, nothing will happen.

 

Enjoy!

iShowU Studio – new features and fixes available for testing!

Hi all!

I’ve just released a first look at the upcoming 1.0.3 build. This is available from our facebook “bleeding edge” group.

The build focuses on the following:

  1. Fixing some bugs (colour encoding problems and audio issues)
  2. Implementing the ‘new empty project’ feature
  3. Making geometry sane

The last one really came about because I was trying to implement the “new, empty project” feature. That should have been quite simple, but unfortunately I’d made some silly decisions early on with regard to how geometry was represented in Studio internally.

I mention it because it was a major amount of work, that’s hopefully totally invisible to everyone. Typical huh? You do all this coding, and no one can tell the difference!

I’m pleased to say that’s all the badness(tm) has been fixed up, and everything is oh-so-much-more-sane now. This change is going to make implementing things like “retina / non-retina quality encoding” really easy.

New, Empty Project

I’ve yet to update the manual, so here’s a quick rundown on where to find this new feature. Go into the File menu, and there’s a new item named “New Empty Recording“. This will create a project that is the same size as the active screen.

To change the project size, go into Edit | Show Info. There’s now a Canvas Size option there. You can change that to a bunch of preset values. I’ll add a “Custom…” there at some point as well.

That’s it! No geometry is changed when you do this. All your objects are left in their original sizes. I figured it might not be best to auto-scale everything, as it may not be the intent of the user.

What I’ve been up to with Studio over the last week and a bit

I wanted to update people on what’s been going on, as I’m aware updates to Studio have been a little quiet.

Bug wise, the focus is on:

  1. Audio sometimes not playing for a newly recorded project. For some people this happens often.
  2. Color of encoded video is sometimes incorrect when encoding after a first recording.

In both cases above, a workaround is to close/reopen the project. I’ve been trying to find the cause of these, but so far no luck.

New Stuff

I’ve also been working on some new features (part of the list of things I really wanted to have in there for v1.0.0 but ran out of time).  For version 1.0.3 I expect to be adding:

  1. Locking of objects.
  2. Ability to create empty projects (without recording screen footage first).
  3. Ability to change the size of an existing project’s canvas.
  4. Few new context functions, like “fit to canvas” and “reset to original” for objects.

The reason why all this has taken longer is because of pt.2 above. It really needs pt.3 to exist so that the new functionality makes sense. However, to get that in place I had to address a pretty major mistake I made in v1.0.0 – using pixels. Bad idea Neil. Bad.

Pixels Suck

That might be a bit harsh. Except when you’re talking geometry. I don’t know why, but for some reason I modelled the various objects within the scene using pixels. I think I did this because “it seemed like a good idea at the time”. I think I also made this “decision” pre-retina.

This made working out what is going on in a retina aware world really challenging to say the least. And messy. I couldn’t brush this aside, so I took the leap to completely refactor the entire rendering engine so that it uses points. When I say “points” I mean “logical what size are you as a geometry” type points. I could use cm’s, or inches (except I live in a sane metric world :-).

Points are our friends. Points can represent things logically.  Consider the case of a 1440×900 MBP screen, recorded at 25% scale. Points wise it’s still 1440×900. The underlying pixels however have a scale of 2*0.25 = 1/2. The real pixel size of the recorded footage is 720×450. But from a user perspective, like when you’re selecting a crop area or changing a canvas size, you don’t care. As far as you’re concerned you still recorded the MBP screen. You want the UI to say things like 1440×900.

Annnnyway, now the underling render model and all UI elements use points and all this is turned into pixels only when needed (rendering).  This has tidied the code base, and I’ve fixed a couple of other weirdo bugs along the way, simply because the whole thing makes about ten thousand percent more sense.

So, that’s what I’ve been up to.   I’m just trying to fix up the project canvas size part now, and I’ll have another beta out. This one is looking to be good!

Fix for iShowU HD crash running on OS X 10.9.3

Summary

For those of you experiencing crashes in HD after updating to 10.9.3, I think I may have a fix.

You can download this directly from this magic link. It’s the same link that’s at the top of the iShowU HD change log, on the iShowU HD product page.

Do let us know if you have any problems!

The reason + rant

It turns out that enabling “record cursor” on the AVFoundation screen input made everything go “bad” ™.  I was seeing out of memory errors, freeing of NULL pointers, all kinds of weird stuff. Nothing in the debugger made any sense at all.  I only found it by going through the code disabling parts of it piece by piece until something changed.

I’ve worked around this by disabling AVF based cursor rendering and using our previous mouse compositing methods that existed pre-10.7.x.  This fix is in place for Mavericks only. iShowU Studio doesn’t use AVF to perform mouse compositing, so gets away without a similar fix.

I have to say (I feel a rant coming on), that this is exactly why I was incredibly annoyed at Apple deprecating (and breaking) the capture functionality post 10.6.x and forcing developers to use their new AVFoundation.  As the saying goes, don’t fix what ain’t broke. The old method wasn’t broken. 

As demonstrated, now all you need is some bug to enter into a system supplied library (like AVFoundation) as part of an update and boom!… apps stop working. I am not impressed.

Grrr. I submitted a bug, Apple requested further info, I supplied said info, and then Apple closed it as a duplicate of some other bug that I couldn’t see.

Think I’ll go do something else for a while, and see if I can make this rant-mode go away.

Document Saving and Asset Resolution

I’d like to provide some detail on the next build, which makes changes to the document saving and asset resolution of iShowU Studio. No idea what I’m talking about? read on!

What’s changing

a) Project / Document saving
b) Asset resolution

Project saving / Document saving is what you think it is. It’s what happens when either OSX or you yourself save the project/document. What’s changing is that (b) above is now mutually exclusive with (a). It sounds like a small change, but could have “bad ™” consequences.  I’ve done quite a lot of testing here, but I’d really like to get some feedback from real users before I make this available as a general beta.

What I’m looking for

Specifically: testing of save’s on new projects, both short and long. Saves on slower devices, like hard disks. Large/small projects. Adding additional media. And, across all of these tasks: renaming a project (which causes (b)). I’m also looking for issues when using / saving existing projects. It’s not *just* new projects that may exhibit problems, just that’s where I’m expecting to see them.

I expect, if it’s going to fail, it’ll be failures like:

  • Hangs. The app becoming totally unresponsive.
  • Failures during saving of documents, or renaming of documents.

If you do have a failure / problem, please can you:

  1. Try it again. Can you repeat it?
  2. Jot down the steps you took and post it here.
  3. Upload the footage if possible (ask for a private DropBox folder if required – we’ve plenty of space).

Where to get it

I’m going to try posting this build, and any other pre-beta builds directly to the Bleeding Edge Facebook group. Lets see how that pans out. Importantly: The builds I am talking about in this post will not appear as updates in the app just yet.

Enough from me! I’ll throw in another note on the above FB group when I’ve uploaded the build.

Heartbleed – we’ve patched our servers

You’ve probably seen the drama regarding this in the news: there’s a vulnerability called Heartbleed that in short affects a huge number of secure servers on the net. Think: shopping carts, secured logins and so on.

Eeek!

Fortunately there’s a patch. That patch has been applied to all shinywhitebox servers. Yay! We’ve also revoked and reissued our SSL certificates (as per the great write-up of the problem above).

As a precautionary measure we recommend that you change your account password at shinywhitebox. You can do that here.  The aforementioned link will send you an email confirming the reset, and it’ll then generate you a new secure password.

Finally, no credit card information is stored at shinywhitebox. if data were stolen from our servers only what is shown in your account details page would be disclosed. All account passwords are MD5 hashed, and so these cannot be decoded either.