Wireless Focus remote

[interactiveartsNI]

Hi,

 

I'm developing an Iphone app to allow a theatre tech to focus DMX fixtures wirelessly, without paying a fortune for an expensive radio system.

 

Here is the prototype http://www.youtube.com/watch?v=owGylkQp2iE

 

The App has 4 functions -

 

1 - DIP to decimal conversion and vice versa, also the dips can be reversed and the 'All off mode' applied, also an offset function

 

2- Basic power calculations

 

3- Focus ability, so a full/clear message can be sent to the driver program

over wifi to send CHANNEL/VALUE pairs to the Enttec Dongle

 

4- A little text pad for keeping notes

 

 

What other features would a theatre tech want from a wireless remote ? e.g. triggering audio / trigger video for testing etc ? Controlling multichannel fixtures like moving heads etc, what is top of the wish list?

if techs could write software, what would they want to make their job easier ?

 

I just need to get some feedback of what techs need before I release this to itunes / or develop other lighting based apps. BTW I'm not using art-net, I use Open sound Control so audio applications can actually be used to control your fixtures too.

 

Thanks, feedback much appreciated

[jonhole]

How about being able to add a list of channel numbers before hand (for example your FOH bar in order left to right).

 

Then, when up on the bridge / in the roof / whatever, you can just press 'NEXT' / 'PREVIOUS' and the app turns the next lantern on, and clears the previous one.

 

Edit: However, to avoid a pet hate, please make sure the app does it in that order, and not turning off the current lantern and then bringing on the next, as this causes a blackout on stage.

 

Also, it's not Iphone, it's iPhone. Apple will reject your app for typing this wrong!

[interactiveartsNI]

ahh iPhone, would never have noticed that, thanks.

 

OK, about the channels on the bar, I thought the idea was to use an offset so you just click the '+' on the app to go to the next fixture, then do the focus, as I'm guessing all the DMX addresses are consecutive anyway, but I see you point if for example a bar has addresses from 100 - 120, and you want to focus fixture on 100, 103, 108 so the offset would have to be 1 and you would end up pressing the '+' 8 times to get to the 3 fixtures, I will have a look at a solution, maybe add a focus que which you could move up and down without even using the full/clear.

 

I take it the que will always start at the lowest, i.e. if you add 10 DMX addresses, the app will need to order them, or do I need an option to order/unorder ?

[jonhole]

Just because the lanterns are in a physical order on the bar, doesn't mean they are patched into the dimmers in that same order. It would need to go along in the order you input them.

[interactiveartsNI]

cool, I'll add 2 more buttons for NEXT/PREVIOUS and use the 'notes' section for a mark up, e.g. <quelist>100, 103, 108</quelist> will store the list, so its a matter of adding more markup tags, and program it so the tech is never in the blackout, i.e. add a delay during the transitions, this should cover it,

[henny]

You will probably have a wider audience for your app if it sent out artnet directly and didn't need a server running on a pc

[interactiveartsNI]

I know art-net is a big favourite on here and standard, but art-net is still a node on a network on IP, but here's why I believe Open Sound Control (OSC) is a strong complimenter -

 

1 - Easy development for a programmer, in c, c++, objective c, java, python etc across mac, windows, iphone, android

2 - Cheap interface, dongle, cheap wireless nodes, prices on the art-net site are expensive and the art-net spec, well...

3 - OSC messages are arbitrary, you can define them, e.g. send a message to trigger a queued sound file, trigger a video, i.e. not limited to lighting, trigger a relay to open your door,I .e. the nodes can have some intelligence

4 - OSC will eventually compete / compliment with midi

5 - Audio, Video and lighting are merging, i.e. communication between these systems needs a standard, so developers can leave sockets open (as security can be handled witht he network)

6 - Use an audio program to control your lights, as knobs and sliders are just controllers

 

Actually there is a lot of reasons, but I will write a udp packet sender for art-net when I get time and if the documentation makes sense, some more info in relation to DMX and osc

 

http://www.dmxcontrol.de/docs/OSC/OSC_Medi...-01-24_engl.pdf

[Tomo]

I would suggest that you don't use Art Net, particularly for a wireless focus remote.

 

There's two main reasons for this:

a) Art Net is broadcast, which all routers block, and many WiFi access points have difficulty with. (Art Net II can be point-to-point after discovery, but the discovery process is still broadcast.)

 

b) Art Net has a hard limit of two controllers per universe. In a theatre with a Main and Backup console, there's no space for your unit because it would be a third controller - you'd have to shut down one of the consoles to use it.

 

I would suggest that you take a look at ANSI E1.31 (Streaming ACN/Streaming DMX, or "sACN")

- This is an international standard from the same body that administers the DMX512 standard.

 

This is multicast so can easily co-exist with other services and can traverse WiFi routers and access points.

Most sACN devices can listen to more then 6 controllers per universe, with many handling even more (they are only limited by their processor and RAM, not the protocol)

 

There is an open-source implementation of E1.31 on SourceForge called "sACNView".

 

That OSC document is interesting - I had not heard of that protocol before.

- ANSI E1.17 (ACN) was ratified some years ago and is already in use in lighting control applications, and it was designed to handle all theatrical and architectural control applications, including sound.

 

You may find it interesting to compare and contrast OSC with ACN, as that is a much closer match than the other, much older protocols listed in the linked document.

[interactiveartsNI]

I totally agree, a broadcast network ? I just read that this morning after doing a bit of research on art-net (thinking about developing a socket to push on the data), but no way, its a massive step back, the network will be flooded and effect all other traffic on a shared 10baset ethernet.

 

I really don't get why artnet is so successful. Multicast is the only way forward, so I will have a look at ACN, as its multicast, it has an obvious advantage right away.

Also the documentation on artnet, I mean, its really bad, and no 'plans' no develop for JAVA (a platform independent language that runs on any os ?) The software needs to run on mac/windows, as mac is getting popular especially now.

 

 

The system must be multicast and easy to implement for developers, artnet is neither, but if a load of people have the hardware, well it will let it live for a while yet.

 

For me OSC is so simple to get stuff up and running, and a simple command '\DMX 1 255' to turn a fixture on is minimal and I like minimal, and also a namespace could be defined for moving heads, pars, etc i.e. standardise an ontology, so you just group stuff together and thats a sub broadcast, so you could just send messages to the fixtures that need them, not the whole network

[mac.calder]

Art-Net is generally a broadcast protocol... it does not HAVE to be broadcast. If you have only a single node, you can send that packet only to that node... It is just that there is no master/slave system in place, and the only thing that knows what each device is listing for is the device (and sometimes the guy behind the console), so if you have a distributed system, then you need to broadcast. Admittedly, most desks don't give you the option, but since you are the one writing the program, you can certainly offer it if you were to go down that route. That said, I am a sACN guy myself.

[Wol]

I totally agree, a broadcast network ? I just read that this morning after doing a bit of research on art-net (thinking about developing a socket to push on the data), but no way, its a massive step back, the network will be flooded and effect all other traffic on a shared 10baset ethernet.

 

I really don't get why artnet is so successful. Multicast is the only way forward, so I will have a look at ACN, as its multicast, it has an obvious advantage right away.

Also the documentation on artnet, I mean, its really bad, and no 'plans' no develop for JAVA (a platform independent language that runs on any os ?) The software needs to run on mac/windows, as mac is getting popular especially now.

 

The system must be multicast and easy to implement for developers, artnet is neither, but if a load of people have the hardware, well it will let it live for a while yet.

 

For me OSC is so simple to get stuff up and running, and a simple command '\DMX 1 255' to turn a fixture on is minimal and I like minimal, and also a namespace could be defined for moving heads, pars, etc i.e. standardise an ontology, so you just group stuff together and thats a sub broadcast, so you could just send messages to the fixtures that need them, not the whole network

 

Surely whether broadcast, or multicast, if you have a universe of DMX going over sACN or a universe of DMX going over Art-Net.... either way you have a universe of DMX being transmitted from your iPhone. The broadcast / multicast argument I'd have said is more applicable for the receiving devices (e.g. if it's not interested, it doesnt want to have to process it to work this out, which is why ArtNet also supports unicast).

 

For a source device, it has to send out all the data to anything that wants it whether unicast, multicast, or broadcast. At the point where the amount of universes being used saturates the outgoing network stack on the iPhone, you'll generally find someone will have a lighting desk which has a proper focus remote. Because of the latency of wireless, *this* is why focus remotes only transmit control commands (e.g. channel 1 @ 255 - 2 bytes), not whole universes of DMX all the time.

 

The documentation on Art-Net available online is fairly simple to follow. Theres only three packets you need to know for DMX (well usually only one if you want to hack it!), and thats just a 512 byte array with a very simple header, so shouldn't be too hard to implement. Also, what do you mean about "developing" for Java? Art-Net is a network protocol, not an application, and thus has nothing to do with Operating system. I've got art-net running on a Microchip PIC18 microprocessor, on Java running under linux, using c# on windows etc.... Have I missed what you mean here?

 

 

Art Net is broadcast, which all routers block, and many WiFi access points have difficulty with.

 

All routers block broadcast packets? What now? All the routers I've used haven't! Considering DHCP is broadcast, any machines with non-statically defined IP addresses would fail pretty hard if broadcast didn't work!

[interactiveartsNI]

OK, I am aware that artnet has a header, spells something like 'artnet is amazing', and that its a 512 array and I am also aware of the difference between Operating Systems, protocols and software that runs on operating systems, let me explain why I believe OSC would be suited to DMX lighting.

 

A pc (intelligent node) on a ethernet network (addressed IP) is interfaced to a DMX universe via an Enttec Dongle

On the universe is say 10 dimmers (for simplicity)

ONE OSC message e.g. '/DMX/dimmers 1 10 0 255 30 ' is sent from say an iPhone which really means 'Dimmers from addresses 1 to 10 go from 0 to 255 over 30 milliseconds' thus turning them on.

 

So lets look at that, I sent ONE message and let the intelligent node (the pc) handle writing out the data to the Enttec dongle, as I defined an ontology i.e. /DMX/dimmers, I could have had something like DMX/movingheads or DMX/hazemachine etc, the point being that if the ontology map was created by lighting professionals, then it becomes a standard itself.

 

The ontology is like a tree like structure turned upside down with /DMX being the root, then /dimmers, /movingheads, /hazemachine being the children, this makes efficient use of the network, and ALLOWS for new extensions to be added, so its extensible, understandable, cheap and would give lighting guys a chance to dream up ontologies to do some cool stuff, e,g, load a sequence / chase on to a node and trigger the chase with ONE message to the node.

 

This is getting of the point a bit, but if you group/define all the common tasks that DMX needs, build an ontology to house these requirements, publish them and then its only a matter of a programmer parsing the messages and writing them down a usb to a interface/dongle, OSC is arbitrary, means you define the message sent, so some of you tech guys in the business for years could actually create an ontology with a pencil and paper and hand it to a programmer, because you will have a lot more knowledge than most developers.

[mac.calder]

Without wanting to turn this into a topic about the pro's and con's of various protocols - there are a few things to note: DMX was designed for dimmers. It has been "adapted" for use with intelligent fixtures (by adapted I mean desks have changed in design to bend DMX to it's use). Our channel use went up, copper is expensive, yadda yadda yadda, so some smart cookies came up with DMX over Ethernet protocols. The advantage is that it just wraps DMX packets, so the processing to convert either way does not need to understand the fixtures, or the desk. It just needs to be able to either wrap multiple universes of 512 channels or unwrap them at the other end. Implementation is cheap.

 

Whilst this whole thing has been happening, some other smart cookies started to design a system called ACN - Architecture for Control Networks. This is a much broader protocol - it is not a "lighting" protocol exactly, it is designed so that an ACN desk can send out a "Who is there" type packet, everyone replies, the desk then says "Well what can you do? and you? and you" and the fixtures reply. It also has the ability to do things like "Where are you?" "How is your lamp" etc. It can also set parameters, and the fixtures can also talk back, ask questions back and even set parameters on the desk. It is almost infinitely more powerful than what we currently have. But it is also a MAJOR shift in how we think fixtures think and work.

 

Here is why the ethernet-wrapped-DMX is a good thing... Many manufacturers have started putting ethernet ports on their devices. Behind this ethernet port is a little bit of processing power - why? - because many manufacturers are "ACN Ready" behind the scenes. With streaming ACN being there to bridge legacy data, ACN consoles will start to appear, and there is a good chance that console operators will need to be prepared for a huge mind shift.

 

Where it gets really exciting is that ACN does not limit itself to controlling lights (as I said earlier), but rather is designed to be nice and open ended, to control "devices" in a network (so not necessarily client server... who knows, lights may start to appear with sensors or some other form of feedback and may be able to be used as triggers). So provided the desk can handle all the capabilities of the devices connected, your "lighting console" could soon also be used for stage automation, controlling media servers (and I am not just talking wind parameter A up, but actually being intuitive about it), controlling projectors, show control systems, hell, even tape decks, routers, coms systems and the like.

 

ACN is exciting.

 

OSC depends more on everyone knowing what they can do, as well as the controller knowing what everyone can do... and we are back at adapting a protocol that was not designed for a situation to fit our needs.