I spent my flight to Montreal (which became much longer than I expected when I was rescheduled through Chicago) reading Trond Lossius’ report for the Fellowship in the arts program. He addresses a number of interesting topics:
Commenting on the necessity for carrying out research for instead of on art, he discusses the concept of “art as code”:
It is not only a question of developing tools. [..] Programming code becomes a meta-medium, and creating the program is creating the art work.
This idea resonates throughout the text, and is followed by a discussion of the importance of craftsmanship in electronic arts:
This text might leave the impression that I am very concerned about the technical aspects of the works I create, with the potential risk of the works to end up having a certain geek factor. I do spend a lot of time and energy researching technical solutions that might help me achieve what I want, but they are primarily means to an end. I consider my practice to somewhat resemble how a professional pianist works. Several hours a day are spent rehearsing scales and other exercises in order to develop and maintain a high level of technical skills. But the development of technical skills is not a purpose in itself, and it would be out of question to play scales and etudes in concerts. The skills are required in order to be on top of the material one is working on, and to be able to articulate oneself artistically without technical limitations becoming a hindrance reducing the impact that message can be delivered with.
I very much agree with this. The tools we use certainly colours what we produce, whether it be scientific or artistic work. Thus, developing tools can often be considered to be the most important outcome of a research process. However, as Trond discuss in the end of the dissertation, such development might often be problematic in collaborative projects:
In stage productions it is very hard to find this kind of time and space alone for development, testing, fool-proofing and debugging. […] Coming up with a new idea might take three seconds, but developing the patch required to realize it might take three hours or even three days, and in the mean-time everything risk coming to a crawl. Most of the time it is hard to say how long the development or alteration of a process or algorithm will take. […] This makes it hard for others to plan other tasks to work on in the meantime, and the actors, musicians or dancers to often end up waiting. When that happens for the second time in a day, energy and motivation is drained, and they struggle to mobilize the presence required for their contributions to the project. […] It is a continuous struggle to find the right balance between working fast so that the general flow of the production is not hindered more than necessary, and investing time in quality assurance, making sure that patches are sufficiently flexible, structured, documented and tested so that they do not cause problems further down the road. I have seen repeatedly when working with others that the importance of this has to be learned the hard way.
This is another point where I totally agree with Trond. Obviously, by developing better and more flexible tools, it should be possible to reduce the time necessary for patching and development during rehearsals. But this is really part of what a creative technologist will have to deal with, and it is important for others to realise that this is actually part of the creative process, in much the same way as traditional musicians need to warm up and practice their scales.