There will be a free full day Korsakow workshop at RMIT on February 18. Places are limited, and participants will be eligible for a 50% discount on the cost of Korsakow. If you’ve dabbled with Korsakow, are interested in interactive documentary, curious, a nonfiction multilinear narrator, or some combination of these, then this is for you.
Korsakow, still open source, formally more or less free, is now USD50 (details on the Korsakow site). This is a good move to hopefully allow more robust development of what remains the best application for authoring generative, thick, multilinear video works for non-programmers (the other options available create link hierarchies, not poetic clouds).
I expect some will be disappointed or upset at the introduction of a cost. However, it is still open source, and in its time as open source developers have not, as far as I know, come on board to contribute. This is the case for the vast majority of open source projects, so if free labour won’t come to your project then to continue development, you need to find a way to bring money to it to then fund that necessary labour.
(And keep in mind that even highly successful open source projects such as WordPress have major commercial ‘arms’ (see automattic), as well as a service economy of commercial plugins, templates, hosting, and installations to make them viable. Similarly many successful open source projects, while receiving donated labour, often manage this via de facto or explicit institutional support. For example Korsakow has undergone major development courtesy of public Canadian research funding, while many others seem to rely on labour by academics who have the good fortune to be employed in positions that allow this sort of flexibility in how they apply their labour. This is merely a form of indirect public funding, which is great, but it is not ‘free’ in the way that much commentary about free software and open source defines free.)
So, at USD50 a licence it will now run under Yosemite. Hopefully on the roadmap is a makeover of the UI and, I’d hope, HTML5 export in some manner that would allow for K films to operate on iOS tablets by dropping the Flash runtime engine. What is slated is the removal of in application transcoding of video, which is a big plus as encoding outside means you know what your video will look like. It also removes what is often the cause of the most problems with novices as all variety of odd video formats, or weirdly compressed video, has been imported into projects only to have Korsakow fall over when a work is transcoded as FFMPEG bumps up against some unexpected data rate, codec, and so on.
The risk, and it is a legitimate one, is that if the UI stays as is people will misread this the wrong way to think the program is not worth the USD50. It is, but these days with the OS X app store it has to look and behave as a cocoa app.
I am writing an essay about interactive documentary. Actually Korsakow. It is very very late. It is remarkably recalcitrant. I am so very nearly there, that moment when the finish line becomes a demonstration of Zeno’s paradox as it seems to move further away the closer you get. It is so close. Here’s a snippet.
My elevator pitch would be that Korsakow is software for authoring generative, associative, and processual films. These films are complex, possibly autopoetic systems that rely on patterns of relation to emerge for author and users.
2014 ASPERA conference website now happening. Program is a PDF. There’s a database doco panel on Wednesday (Elvira Calatayud, Dean Keep, and JT Velikovsky), and our panel (me, Bettina Frankham, Hannah Brasier, and Seth Keen) on Thursday, with a Korsakow workshop Thursday afternoon.
I’m running a Korsakow workshop as part of the Australian Screen Production and Education Research Association annual conference. It’s in Newcastle this year. If you’re at all interested in seeing the software, and you’re attending, please come along. There’s a bunch of us also presenting papers at an interactive documentary panel during the conference too.
A common scenario witnessed this week in classes with media students. They add stuff to a new project in Korsakow, add keywords, do lots of building, and then go to save their project. The program doesn’t like that. I’ve written an explanation for them that most (the majority) won’t read, let alone understand. The problem here is thinking that the digital is supposed to be friction free (I blame Apple of iOS for this), that it is immaterial and, well, should be designed and made so that I don’t have to know anything about it, or what I’m doing. Digital natives my arse. Just because you can drive a car doesn’t mean your a mechanic, and just because you can use seven programs at once and know all the best shortcuts in Final Cut/Premiere/Photoshop/gMail you’re not digitally native. You need to think like the machine (like a good mechanic), and you can’t do that if you haven’t got a clue about the machine. It’s a thing. It does stuff. Real thing. Real stuff. Not virtual. Not immaterial. (Which is the cardinal sin that the NFBs big arse ‘capturing reality‘ has made, but that’s for another day.)
labs, this week
Launch Korsakow. “Ok…”, drag some video in.
“Mmmm, Ok, that wasn’t so bad.”
Double click. “SNU editor? Whatever.”
Make some changes, add some keywords, link to an interface, and a thumbnail (“What’s the drama with this?, this is easy”). Repeat.
“Cool. Oh, better save the work.” File, Save.
It’s all gone. “F$#kn rubbish piece of software.”
If you don’t want this experience then open Korsakow, and SAVE THE PROJECT BEFORE you add media, and you’ll be good. (Subject to good housekeeping.)
If you want to know why, continue reading (you are asking the software to do something impossible).
When you drag or insert media into your Korsakow project you are not putting the video ‘in to’ Korsakow. Korsakow just remembers an address of where your video is and so when you do an export it uses this address to go and find the video, and then transcode it when you export (publish) your film. This address is called an alias, and Korsakow relies on an alias, which is in effect a link to the real file, to find it.
Lots of programs use aliases as a way to have multiple copies of a file without actually having multiple copies of the file (incredibly useful when working with video), and it’s built into the Finder of OS X (File – Make alias, aka Command L). That’s pretty straight forward. Korsakow does this so that it doesn’t have to swallow video, which introduces all sorts of storage and data problems which would make the program slower (since it has to process all that video) and less agile (as keeping the media outside of the program makes it much easier to change the media as you go).
How do aliases work? By addresses and paths. All the files on your computer, much like everything on the Web, has a file path, which is its address. On a modern Mac this begins with / and then is a series of folder names and eventually a file, so a word doc in my user account on my computer might have the path /Users/amiles/Documents/somewriting.docx (That example isn’t strictly accurate but it will do.) This is its address.
Now we saw that Korsakow needs to know and remember the address of where your video is when you add it (which is why you don’t change the names of files, folders, or where they are on your computer after you add them to Korsakow unless you want export hell). I imagine it does this in the simplest way, which is to remember where these media files are in relation to where it is. On computers we call this a relative address. In other words if it knows it is here, and the video files are in a folder called ‘media’ next to it there, then Korsakow only needs to know an address that says ‘media’ to be able to find those videos. Now the program could me made to remember a full path, all way to the top of your computer, but then if you moved your project to another computer all these addresses and paths would break. By remembering where the media is relative to where the program file is makes it easy to move the project to other computers.
These relative addresses on a computer are just like personal directions you give someone in the street. When asked how to get from Carlton to Brunswick you don’t tell someone to first go to the Melbourne General Post Office, you say go up there, turn left, then right, etc – these are directions relative to where you currently are.)
Can you see the problem? If you haven’t yet saved your Korsakow project file (the file that ends in .krw that stores all these aliases) then how can it know where it is? And if it doesn’t know where it is how can it then find a way to where the video is? Now yes, just crashing is basically a bug. But it is happening because you’re asking a program to do something impossible – to think about the relative address to somewhere else without first telling it where it is. The fault here is with us, not it.
In network media I discussed small world networks, dense nodes, and so on. A korsakow film is exactly this sort of structure. Below is something I wrote in 2011, reposting here as it should help people to understand Korsakow films as an architecture and structure that you do things with, and an architecture and structure that is, in its very DNA, the same as the networks we are working on. It’s sort of a mise-en-abyme moment really.
A significant idea that has a lot of relevance for things like the internet, hypertext, and social media (which are all forms of distributed networks) is the idea of a ‘small world network’. This is related to the famous experiment by Stanley Milgram about there being a maximum of ‘six degrees of separation’ between any two people, anywhere in the world. A small world network assumes lots of a small number of connections between individuals (nodes, clips in a k-film, links on the web, people you know), but with a few individuals who have a lot of connections. In relation to social networks these links are not about how close you are to others (whether geographically or personally) just that you know them. The existence of only a small number of people who know a lot of other people (who have a lot of connections) makes it much easier to get from one group to another, from one individual to another. The key features here are that these connections (how many people you know) is not equally distributed – I know 100, you know 200 – and that to get from one individual to another you do not need to know all the connections, all you need to know is somebody that you think will be closer than you are.
So, what does this have to do with k-films? Quite a lot, since keywords create (in k-film land) small world networks. Clusters or clouds of clips that all know about each other since they have common keywords. Now, imagine a work which has several such clouds. This is like a party where there are four, no let’s make it five, distinct groups of people who know each other. Now, to find someone in my group who knows someone in another group (in other words someone who could easily sit in one or more of the groups) is quite easy and this is how the two groups can be connected. The person I know in that group over there can introduce me to everyone else in their group – I just need one point of connection to be able to join them, it doesn’t matter that I only know one person.
Hence in my k-film with my clouds all I need to do is make sure I have one clip (node, SNU, pick your term) that has lots of connections to the other clouds. To keep my now rather dodgy analogy going, the person who knows someone in three, four or even five of the groups at my party. This node might have no limit to lives (it will keep appearing) and also have plenty of keywords so itn is a point of connection to all the other clouds and nodes.
In practice I might have most clips with limited lives. As I view the work I am caught in a cloud, but as I view material and clips ‘die’ this special node (what I’m currently calling a dense node) will appear. If I select this then because it has links to all the other clouds I can now get access to these other clouds. In this way I’m able to make sure that all the parts of my k-film can be connected. That’s one half of the problem. The other half is to figure out how to film or make this content in such a way that it makes sense, visually and contextuallly, so that it works as this dense node or hinge between these other parts. This depends very much on what these other clouds are about.
Need an example? I might have material that I have grouped (made as clouds) around night and day. I might then have to fllm something at dusk or sunset and use that as something that connects night and day and make this clip my connector. I might have inside and outside, light and dark, blue and red, and so on. In each case once I recognise what the terms of my structure are I can identify something that falls between them, and this is the one that I can use to join these two clusters or clouds together.
Korsakow is a system that encourages promiscuous connections between video clips. This doesn’t mean lots of lots of connections (though it might), but it does mean that this clip might hook up with that clip, and that one, and that one. And, not or. A way I characterised some of the confusion, and perhaps anxiety, about systems like Korsakow in a symposium today was around this idea of how promiscuous things become. In linear media it is all monogamy, or more accurately a literal serial monogamy, where that clip will always end at exactly 12 seconds, forever (at least until death does do us apart) and then this next clip will always and forever then appear. And play. As makers we don’t seem to want that order to be fucked with. (And lots of interactive documentary is as strident about these strict connections as heritage media with its single channel of constrained cause and effect always-just-this-way.)
My students, in spite of the nonsense of being ‘digital natives’ (now there’s a misnomer) remain highly invested in this notion of monogamous media (reified as the truly important story I have to make in just that way) and remain bemused, startled, threatened and at at times troubled by the looming promiscuity of connection they are being introduced to. We need to learn how to dance with these fragments of our and other’s media, letting them touch and slide and swoon and caress and bump and grind and abut. (Some students, however, are relishing it.)
Future time based media forms and practices are all about this dance, and while I’m not much of a dancer myself, these young people need to learn to get over their reserve.
I’ve made a k-film that is very linear. Well, not linear, you can listen and view the clips in any order you like, but it is not so much a k-film as using Korsakow to collect some screen casts together where I go over some things to think about in relation to making your k-film projects. This was made using Korsakow 5.0.4, and I’ve included a playhead in the interface which shows you where in the clip you are. The advantage of this is that it immediately tells you how long a clip is, since if the playhead progresses very slowly then you know it is a long clip (and vice versa).
So, the k-film. It is commentary on some of the things to think about in your final projects. I made it as a k-film because it was just much faster to talk about this stuff and record it than trying to write it all out. YMMV. Click the pic go there.
Found this from a static site from 2010 or 2011. This is about Korsakow as hypertext, not the linear singular link node notion of hypertext that everyone who writes about interactive documentary thinks hypertext is, but the sort of hypertext that hypertext theorists and writers use everyday (for example with tools such as Storyspace or Tinderbox).
Korsakow is software. It lets you make and publish multilinear video (and sound) works online. That is pretty much all you use it for and all it does.
Some questions: why do we use it? What might be learnt from using it? What can we make or do with it?
How to Think Korsakow
The Korsakow System is software that lets you make hypertexts. Unlike traditional hypertext the content nodes here are now video or audio, but all the principles, rules of making and reading are pretty much the same as for hypertext (or I guess more accurately hypermedia).
The simplest way I think of understanding the Korsakow System is that it is a system for making what I think of as hypertext movies. It lets you make links between nodes like you do in HTML, except the links are not written out as HREFs but use keywords. Each clip in your project These keywords can also be attached to time.
This means that you should think of a keyword as being the same as a link, so a video clip while you are making a movie can have links out to other video clips in your k-film. This means any clip can have as many links to other clips as you like (there is even a random option where it will insert any clip for you, think of this as a random link to all the other nodes/clips in your project). Similarly there are links in to each clip from other clips, and you define these as well.
Figure One: Standard Links Using HTTP and HTML (HREF attribute).
For example, as Figure One illustrates, the sorts of links commonly understood to constitute hypertext are those written in HTML, and so are anchored on a source page (for instance in text or an image) and when selected have a single destination which is to a legitimate URL. Hypertext however, has always had much more sophisticated notions of linking than this, including the assumption that you could link from the entire object (in the case of Figure One, this would be the entire page), and that any link may have a single anchor, or source, but multiple destinations.
In such a system (see Figure Two) a link may come from an entire node, or from any part within that node (and a node may contain text, image, video, and so on) and may have multiple destinations. In many traditional hypertext systems this is realised through a link with some sort of dialog or directory window opening when a multiheaded links is selected to let the reader choose which of the destinations they would like to arrive at. Alternatively, such systems may also institute rules so that the system, rather than the user, determines the destination from those available (Storyspace is an example of such a system). Such rules usually rely on state information (that is the system records what you have been doing, and so knows what nodes you have in your history, which word you just selected to follow a link, and the like) and so make links available on the basis of reading history (what you have, or have not visited) and text strings (what bit of text you have selected.
However, technicalities aside, what is of importance here is the difference this sort of hypertext has to plain vanilla HTML with HREFs. In the latter links are singluar with a nominated and visible source (the link anchor) and a single destination (a URL). This means links can be thought of (and mapped) as complex, recursive tree structures, but the connections are all fixed and visible, whether they are followed or not – this web page has n links with n1 destinations. In Figure Two though we don’t have such tree like structures (I should stress that ‘tree’ really is a misleading analogy, since a web link can link to any other URL and there is no necessary hierarchy required, which the tree analogy suggests, but I do want to provide a strong sense of the way in which these sorts of links are ‘flat’ compared to more complex hypertext structures, are easily discoverable (ie you can just see them) and so describe and create a fixed topography whether they are followed by a reader or not. This is, after all, how a spider like Google can index webpages as it follows links, it is premised on them being explicitly declared, described and able to be followed). I like to think of them as clouds, or as fuzzy links.
Figure Two: Multiheaded Links in a Hypertext.
Clouds and Fuzzy Links
These are quite informal terms, but that’s OK. They are fuzzy because in Figure Two the link that has four possible destinations does not need to be made up of four different links (as would be the case in HTML) but can be a single link which has a condition or rule attached to it where that rule is satisfied (in this example) by four destinations. This lack of specificity, where a link does not absolutely go from here to there, is what makes it fuzzy. It might go to N1, but it might also go to any of N2, N3, and N4. As a consequence of this the structure is not fixed as in HTML but is cloudy, there is a soft constellation of potential destinations, and they are potential not because it is a web page with ten links and the reader may decide on any of the ten (or none) but because the destination is actuated by the system in response to the user as a feedback system.
Now, let’s return this to Korsakow. Korsakow uses the model described in Figure Two. The link is not a link in the technical hypertext sense (though it is, after all a hypertext system such as Storyspace is, like Korsakow, a database application with a particular sort of presentation layer for authoring and reading) but a keyword which enables a search. This search will, in the simplest scenario, match all other nodes that contain this keyword and so make them available for selection – in the first instance by the system and in the second by the user. In a k-film the set of possible destinations to a key word is constrained by a) the number of nodes containing that key word, b) the number of lives each node has (which limits the number of times it can be played, which in turn limits how often it can appear as a result of a search), and c) how many thumbnails have been allocated to present the outcome of the search.
For example, in Figure Two we have four nodes that have links, so as a k-film that would be four nodes that contain the same key word that we are searching for (keeping in mind that this could include the same node that is the source of the search). However, in defining the parameters for the first node in this series it is possible to limit how many results to return for this search, so while there may be four that meet the condition only two (for example) may be displayed. Similarly the designer of the k-film is able to determine how many thumbnail panes to present in the project, and this can also affect how many nodes within this ‘cloud’ may actually appear to the user. For instance, a k-film may only have three thumbnail panes, so if there are four nodes that match the search criteria, one will not be displayed. Finally, it should be obvious that as more material is added to a k-film project the set of nodes that matches a search may change as more nodes with the same key word are included.
So, we have links that are fuzzy because they are rule defined, and what meets the conditions of these rules varies due to a variety of author defined constraints. A problem remains though, as an artefact of our visualisation, which suggests a linear passage through the material (from left to right, and implicitly from beginning to an end). This is, in fact, not the case.
Figure Three: A Sketch of the Structure of A Completed K-Film
Figure Three provides a concpetual link structure for a simple k-film. The coloured lines are different key word links between each of the nodes. The point of this third figure is to begin to suggest the complexity that can be built through only a few nodes (SNUs, lexias) and keywords, and that the structures (the sequences) are recursive, circular, and ‘ill formed’ in that they are not explicit like in HTML but lie there, as a virtual set of possibilities.