Archive for December 8th, 2008
I will resist the temptation to live-blog furiously about January the 14th 2009 and round vs square boxes.
Zicarelli raises some interesting questions regarding the nature of programming-as-art, programming-as-tool and the possible fusion thereof.
The cycle of deception. Program, tweak, observe, judge, … What is to be the metric of success for computer music? Perhaps, more cynically, how pathetic must that metric be if our craft with programming-as-tool is so poor that we really have an incomplete understanding of the machine we are creating?
The importance of fluency: The quality of the tools are reflected in the quality of the result–artistic or functional. At the same time, to that end, the ease of use can be improved so that the user may gain a fluency that allows the constraints of the environment to be minimized.
Transcendence. What happens when we are free of the cycle and achieve fluency. More importantly, how do make sure the path to get there is unobstructed.
Anticipation leading up to the gathering
A real sense of anticipation for this Jamboree. I had had a very apprehensive feeling walking from the Metro to STEIM on my last visit back in November, my first time back since Michel’s passing. It was enormously reassuring to see the place well, and just keepin’ on going. Then the news that financial support had been reinstated was a joy of relief. The Jamboree affirms this continued livelihood and liveliness of the place, and the community.
I rushed up on an early train Monday to be able to work w/ Jorgen to finish my instrument, and as I worked away in the workshop, the afternoon leading up to the first session was a wonderful reunion. David Z walked in, first visit to STEIM, went out for lunch w/ Frank and Taku. Then there was Dan Overholt in the software room, tinkering around w/ his new touch-joystick instrument. As if he had never gone away. Then I turhed around and Sukandar had walked in -
David Zicarelli, founder and CEO of Cycling 74, company behind Max/MSP, introducing the design decisions behind the very different Max 5. The design improvements really reflect an attempt to incorporate creative users needs, aiming for fluency in programming so that the creative process is allowed to take the foreground.
I particularly liked the feature of presentation mode which recognizes the different processes of building/programming and testing, allowing two different views of the same patch to be open and worked on at once. This division of the programming process and the interface starts to recognize the conceptual mismatch between the process of technical design and the creative goals. Why is it that many Max users play around with their patches without having a predefined idea of the outcome that’s needed? Why does Zicarelli express surprise at this? Musically, how close is this kind of working to improvisation rather than composition? Does Max/Msp facilitate a way of working that allows fluency of conceptual musical ideas and not just technical fluency?
In using Max/MSP I tend to push the material around until I get the sonic results I want. I don’t try to define the outcome before embarking on it, I concentrate on the process. I aim to let the ‘material’ - the data I’m processing for example - find characteristics audible in sound that I wouldn’t be able to predict before I hear it. Sound is not programming! There needs to be a possibility to play with the sound while building, to play with the programming, to change, to tweak, to experiment, to allow mistakes, to allow the possibility of discovering new ideas, and to ultimately shape sound in ways that are not limited to the conceptual thinking of the programming language that it’s built in.
This is why I like Max and still work with after 10 years as the program of choice for the work that I make. But, as was pointed out by Zicarelli, I am one of a shocking minority of women in the Max/MSP community of users. Why? Why do I like it? Why am I one of only 4 women in the room? It points to a larger problem visible in the minority of women in electronic music.
David’s attention to the male dominance visible in Max, is at least an acknowledgement of the problem. But it cannot be seriously considered by following with jokes on the female nature of the roundness of button/bangs in the graphic interface a joke that made all the men in the room laugh, alienating the women, and continuing to talk on a male level.
Frank introduces David as a huge source of inspiration for him to develop software.
David starts with mentioning that he’s glad that STEIM is finally open enough so he could visit .
Max 5 was started for a big part from scratch, since the Max 4 source was still based on 80’s programming. Aside from that it’s always difficult for programmers to not be able to get rid of things in the software because people are so used to it…
‘Programming is relatively easy for people - using the computer is far more difficult.’ Getting started is the problem. How do you learn the program? Printing out the manual? Displaying the manual onscreen, which doesn’t really fit with the program itself? All documentation is written in XML format, all rewritten with Luke Dubois. What do people use on the computer? A webbrowser! Another program: iTunes. There should be a database of things they care about. Another thing: convert the program to use unicode - especially usefull for user in Asia.
1 - not to “give people a hassle” when using Max (backwards support from earlier versions, etc.).
2 - it should support the cognitive aspects of “being creative”.
3 - allow the process of creating something to transcend the actions of drawing boxes and lines, in order to make something that “means more” - allowing users to develop through cycles of a) thinking about the structure of the software and b) being users of their patches.
Taku, STEIM’s artistic director and curator for most of the Jamboree events, welcomes the audience and guests, mentions the rough year STEIM has gone through, and the fact that STEIM will continue. He presents Dick Rijken as the new director, who talks a bit about Michel’s passing and his new role.
Then it’s Frank’s turn. He starts with an introduction on the hardware development at STEIM, from the Sensorlab to the junXionboard. Dan Overholt helped developing this sensorinterface. The idea arised that the software to support the HID USB interface should be more powerful than the small little utility we had then. Also, the Sensorlab code was very much a programming language, while most musicians don’t want to become a programmer, and Frank ended up writing all the setups, making the musician dependent on STEIM for their setup updates. So junXion should be userfriendly, no scripting language. But powerful.