“Weak currents”

As I was reading Justin’s case study reminded me just how important it is for audio-visual consultants to be involved in a project from the word go. When this is not case things can get very interesting. Here’s a story from my life as a designer.

A rich benefactor has a vision – to build a really wonderful concert hall. He gets together a bunch of wise men and women to realise his dream. Architects, acousticians, structural engineers, electrical engineers and HVAC specialists.

But wait says the patron, let’s also put on operas, and show films, and theatre, and let’s make some money by holding conferences. All great ideas! The design team look worried at first, but soon they are rubbing their hands and looking forward to putting their grandchildren through college on the back of this project…

As the last concrete is poured, the electrical engineer mutters something about “weak currents”. Sounds like a minor detail. But indeed,  there is some infrastructure needed that no-one has thought about. Those “weak currents” that carry the audio, video, lighting control, comms in fact everything needed to make the building fulfill its proposed function. About time isn’t it to bring in the “weak currents” guys?

Nothing like the last minute for the audio-visual designer. And somehow he’s expected to equip the building with state-of-the-art systems when no-one else on the team has given a moment’s thought to providing space for equipment, control rooms, cable paths, places to mount lights etc. etc.

A familiar scenario? Let’s look at the impact of this awful decision.

weak currentsControl rooms with no access to backstage areas. So a shabby-looking technician has to elbow his way through the foyer crammed with well-dressed paying audience. Not good.

What about interpreter booths for those conferences? We’ll squeeze them in somewhere. Aren’t there standards for these?

To get light onto the stage you need at least some holes in the ceiling to poke the luminaire through. Did the acoustician think about that? Now we’re in a bargaining exercise for each and every lighting position.

Sight-lines? Not good for films if you can’t see the screen. Key-stoning? What’s that? Big projectors are kind of bulky and produce quite a bit of heat. Any air-con in those minuscule control rooms? No, let the technicians have a free sauna.

Who needs cable paths? Isn’t everything wireless these days? Anyone think that some signals don’t travel well so you can’t route them all the way around the building? That’s assuming that a path can be found. In an earthquake zone structural engineering is a serious business. Each hole needs the building to be re-calculated. Not to mention the cost of drilling through 1 metre thick reinforced concrete.

All in all a recipe for a massive budget overrun and a permanently unsatisfactory result. So it’s good to see some projects like Justin’s getting it right.

When you’re building a new venue of any kind get the “weak currents” people on board right away. They’ll save your project.

Beyond pretty pictures

Computer-aided design when it first appeared swept away a mass of drawing boards, scale rulers, compasses, protractors and the highly trained draughtsmen who used them. Gone were the traces of Tippex and eraser marks. CAD became synonymous with neat plotted scale drawings. But I still come back to the question “how much is the computer really aiding me as a designer?”.

In the ’90’s I began work at a company and was momentarily impressed when I saw them using a spreadsheet program for their quotations. Until I realised that the secretary was adding up the numbers on a pocket calculator and typing them in. Nobody there knew that the computer could do sums! For them it was just an infinitely erasable piece of paper. And in a way general-purpose CAD software still seems to be struggling to leave that phase.

For sure we have 3D now and there are many special purpose add-ons to CAD to help with a multitude of design tasks, but very basic real-world concepts are not built in to the software at a deep level.

For example in my world of audio-visual technology we work with connectivity. Equipment joined by cables. The concept of a connection, ubiquitous in our world today, is a perfect instance of what’s still missing from most CAD software.

Too often by the time an add-on product has matured the problem has moved on. What we really need is a fundamental shift.

ideas for people

Design is about creating things that people will use. There’s a lot more involved than just the dimensions of objects. It’s about making things that work. Computer-aided design should help us to try ideas out, see things working, and catch problems before they arise in reality.

Yet even now most of the design process – the actual thinking behind it, is more in the designer’s head than in the CAD model. And the key word here is model. CAD drawings are still a very limited model of the systems they represent. To broaden and deepen the way in which designers work with CAD the software itself needs to evolve into a system modelling tool.

“A picture is worth a thousand words”?

Not in the world of CAD it seems. Just look at it – our drawings are still full of text: text to explain what the lines actually mean. Not exactly visual communication nor even helpful to the human mind. For sure text is needed sometimes but what about colour, texture and shape? Text belongs to the logical one-thing-at-a-time left brain. But it’s that massive integrative power of the visual right brain that lets us understand things at a glance and see the big picture. This is the power of a good drawing.

A few years ago I found myself writing code to grab desk ID texts from office drawings and integrate these into smart desk objects so we could model who was sitting where and how well the design fitted actual human needs. This “non-drawing data” ought to be an integral part the model, not something  sprayed on afterwards.

In the construction industry Building Information Modelling (BIM) is finally moving in the right direction. Now at last we can ask the question of a drawing “how many windows are there in this room?” and get a sensible answer. How long has it taken for the CAD system to “know” what a room is and what “in a room” means?

modelling not drawing

Highlighting the issues is the easy part. Knowing what to do about them is another thing altogether. I’m not short of ideas.

We need to move away from drawing primitives like lines, rectangles, arcs and text, and start drawing objects. Yes, these will contain all of the above but they will be functional models of the real-world objects they represent. Their properties won’t be limited to drawing attributes. They will “know” where they are in relation to other objects. Visual properties e.g. size, shape, color etc. will be able to be linked to other properties of other objects even bi-directionally. Imagine being able to drag the height of a rectangle and change the temperature in your model. Or being able to visualise that as a heat map?

We need a class hierarchy of objects that inherit properties from their parent classes. And we need to be able to link class properties with properties of specific objects or external data sources to visualise the effect of changes and engage that right brain.

Objects should be able to consume resources from other objects. So often design problems revolve around figuring out how much or how many we need. Resource usage gives us that in a nutshell.

questions, questions…

Creating a model lets us ask questions. Once our right brain has seen and liked what we’ve done, we still need to analyse the design and present the information in a step-by-step manner for implementation. So now we need to treat the drawing as a database.

There’s no need to re-invent the wheel here. SQL should be built-in to all CAD programs. Of course we can add lot’s of nice UI to help users build queries, but that’s the power we need underneath.

How to express the answers? Visually of course! Queries should be able to drive the drawing and give us pictures as well good old traditional tables of text and figures.

complexity and where to put it

There seems to be a law of conservation of complexity. You can move it about, hide it in corners but you can’t get rid of it. And I realise that what I’m proposing is complex. But so is the real world we are trying to model. So the question is where do we put the complexity?

For the purpose of designing a model it’s nice to deal directly with objects and their properties and relations. This keeps complexity distributed over the model and local to the objects.

But any programmer will tell you this is hell to debug. Dependencies all over the place can lead to hours of work trying to track down what’s happening. So we need to find the sweet spot. And I think it’s this:

Although you create and edit locally to objects the actual “code” that executes the model should be stored and run from a central place so you can step through and see what’s happening. This also has advantages for delivery. Quite often you want to give a client a snapshot of how your model looks but not the model itself. So having the intelligence outside is handy.

signing off

As the developer of an add-on to Vectorworks, I often feel with connectCAD that I’m struggling to add features that should really be part of the platform. And Vectorworks is one of the better platforms. It already has a lot of advanced features that were in it from the beginning. But linkage and connections are still a tough call.

Expressing  frustrations does one good of course. But I also hope that we can move towards a new era of design software where the designer spends less time trying to guess the outcome of  decisions and more time in a genuine interaction with a model.

What is the future?

Just to get away from CAD issues for once… well almost.

The world of broadcast television is headed for a disruption similar to what Skype did to telephony. And it’s all about IP. For years now broadcast technology has been using more and more standard IT infrastructure. As computers have got faster and faster software has become capable of doing the jobs that once needed custom hardware. So now where are we at?

Let’s look at what a TV station does.

We take in content as streams and media files, adjust them to our standards, add branding etc. and create… a stream.

Until now this process involved cumbersome conversions of incoming media into broadcast signal formats (e.g. SDI) to do all the processing and monitoring etc. But we are seeing software products emerging that can take the incoming content as is, and produce a branded stream. That renders existing playout systems obsolete.

So what do you need to do this? Well in terms of hardware basically nothing. You can rent storage and processing power from cloud providers and deliver your stream anywhere on planet Earth. Removing a whole swathe of capital investment from the equation!

For broadcast engineers this means a gradual phasing out of in-house plant. Systems design gets a whole new focus. The hardware element moves out to the design of bulk IT plant, and the workflow aspect becomes an exercise in visualising the flow of content.

Broadcast is not the only area that will be swept up in this revolution. Audio-visual is fast moving towards IP-based systems. Again distribution and routing of AV becomes the province of IP networks. Audio is already there with systems like Dante. Video is coming on fast.

Systems design is not dead. You won’t be able to just hook everything up to a network and hope it will work faultlessly, but the design process will fork into  two-levels: function and implementation. The design of hardware will focus on providing “pipework” of the right size for the anticipated traffic. And function will be abstracted into the configuration of the network. Since the line between configuration and status is a rather blurred we could well be seeing diagrams linked live to the systems they depict and providing control, configuration and status in one go.

All a far cry from the world of patch panels.