The nature of the common console is that the consoles in different laptops have to update and control each other. As a result, it is very easy to enter into endless, escalating feedback loops that can crash the computer/s involved. As per the diagram A, anything Malek does on his laptop (say set a tone generator to generate a sine wave at 440 Hz) must be communicated to my laptop so that we are both appraised of the current state of the tone generator. If he turns his dial from 1 to 440, I have to see the dial on my screen go from 1 to 440. By the same token, anything I do on my laptop must be reflected on his laptop. As diagram C shows, unless special measures are taken, the machines can wind up sending messages to each other until they crash.
Obviously there is a need to distinguish between two kinds of signals. We started calling them control and display signals. They are different in that a control signal propagates itself. It affects both the unit it is sent to and every other unit that unit is connected to. A display signal on the other hand, does not propagate itself. It is sent to a unit, the unit receives it, and sends nothing on. The signal ends there.
As it happens, the coders of Max/MSP have built this distinction in. So for example, if you send the number "440" to a dial or a number box, the dial/box will display the number "440" and cause the number 440 to be sent to any other units downstream from them. On the other hand, if you preface (or "prepend" as Max has it ) the number with the word "set," as in "set 440", the dial/box will simply show the number 440 without passing anything on.
However, we found that even though we understood this, we kept on making connections that caused feedback loops. Even relatively simple patches in Max can look tangled, and it is not that easy to spot feedback loops, especially if the loops are completed only when a different computer runs the same program on the network. Time and time again we found ourselves giving the other a patch that worked perfectly fine when we built them on our standalone machines, but went completely nuts when it encountered its twin on the network.
It didn't help that patches we made where nowhere as simple as the synth above. They were complex and nested things, boxes within boxes, boxes triggering other boxes, etc etc etc. What we needed was a way to "see" what we were doing.
Accordingly, I came up with the idea of likening the units to the parts of a knife, and classifying them as either handles and blades. I also decided to add one more type to our taxonomy of signals. Aside from control and display signals, we would acknowledge OSC signals (Open Sound Control signals) which were sent between OSC transmitters and OSC receivers, and which could be transformed into control and display signals.
According to this scheme, blades receive control signals, but are forbidden from sending OSC. Handles, on the other hand, are a mirror-image of the blade: they send OSC, but are forbidden from receiving control signals. Blades can be controlled both locally and remotely, but handles can only be controlled locally.
By creating this conceptual dichotomy, we acquired the power to judge whether a given unit/structure/connection/mechanism was "loop legal" as it were. Once a given unit was identified as either a handle or a blade, we were free to control blades with other blades, control blades with several handles, send and receive display signals between any unit, and so on, without fear of creating a feedback loop.
I see these concepts and pieces of language as one of the products of Coding Tuesday. I go into the evolution of the concepts in some detail to illustrate how the same kind of punk, DIY outlook that underlies the technical experiments can generate analytical concepts and technical language. Language useful and concrete, created out of immediate need, without recourse to books or the internet.
No comments:
Post a Comment