Every year, I team up with raider.no to arrange a party in Hurdalen, or around the Oslo area. And one of the things that is important for us (especially me and William), is to create a cool opening show, using our own innovative technology. We don’t have a lot of money in the organization, so we tend to also develop stuff that already exists.

This year, we wanted to do the timing of the show entirely in our own system, as we weren’t satisfied with the Avolites Pearl systems own “show timing” system.

So we split up the task in two daemons and a GUI. The two daemons are written in C, and the GUI in Perl (using the Catalyst Framework).
The first deamon is the “DMX daemon”, which handles existing DMX data from the Pearl mixer as the rest of the night will be run from this board. This is transferred via network over the ArtNet protocol. It also listens for our own udp DMX-commands, which includes simple operations like, fade (linear), blink, subtract, add, etc. These functions allows external scripts and programs to send simple commands to control the lights. For example “fade channel 1 from 0 to 255 in 2 seconds”. Which would then automatically execute, without the client having do anything more. You can also group together a bunch of actions in a “transaction”, and then have it execute as soon as you send the “end transaction” command. The resulting DMX data is sent to the Enttec DMX dongle connected to this computer. The system is so lightweight, that there was no noticeable delay from using ArtNet->DMXDaemon->EnttecDongle over network, than using the direct DMX output from the board. The nice thing is that, if we want, the show daemon can forcibly stop all data from the Pearl mixer, or even alter the data using add/subtract/max/min commands.

The next daemon is the show daemon, this takes complete scripted shows from the database (created by the GUI), and converts them to commands to be sent to the DMX daemon. This daemon uses (lib)jackd2 to fire events at the exact time according to the sound file playing in a external program like Ardour, which sends timecodes via jackd. The show daemon has functions to group together effects that will be executed at specific timestamps.

Here’s a link to a overview of how we wired it all up for the show.

The whole system is kept open-source at github.

I’m feel that I am starting to get the hold of C programming. But every now and then, I get these “ahaaa” moments, that I am a bit embarrassed about. One of these “aha”‘s I experienced today is how/when C handles initialization of variables where you don’t explicitly initialize them yourself.

Consider this code:

1
2
3
4
5
6
7
8

int var1;
 
int main(char **argv, int argc) {
  static int var2;
  int var3;
 
  return 0;
}

Here i deliberately did not initialize any of the variables to make an example. The first two variables will automatically be initialized with 0 before your main() function is executed. The last variable lives in the stack and will not be initialized unless you explicitly do it yourself. So it will probably have a ‘random’ value. Thats kind of handy to know about ;) I feel like this probably is one of the first things you usually learn about C, but I had totally missed this. Nice to know. Also if you use Valgrind to check your code, it can be very good at following uninitialized stack variables. It will actually follow uninitialized memory bit-wise.

First I thought the memory was initialized to 0 at compile-time, but after some reading, I learnt that the compiler records the amount of uninitialized memory for global and static variables, and stores the amount of data required in the BSS segment of the program. This way the executable will not grow in size in line with the amount of uninitialized data. For this reason some people call the BSS segment for the “Better Save Space” segment.

I have often been very thankful of people who blog/share about things they find out on their own, and want to help others find it out quicker, or just to make little known, but awesome, features more visible. So I thought, maybe I should start to write these small posts about stuff i find, or stuff I want others to know about. So here goes the first.

Remote X applications

Have you ever wanted to run an x application from a distant server, but don’t want to bother with installing VNC or installing anything at all? There is this little known feature in the standard OpenSSH client, which will proxy your X display connection. It’s as easy as running this from a terminal window:

ssh -X myuser@remote.server.net

Now, after you have authenticated, you can start x applications. For example xclock, or kdevelop or other nifty stuff, and it comes right to your local X windows.

Remote connections using SOCKS

When you develop against remote web services, people often restrict your access by your servers IP address. This way only your web server can connect to the web services. But sometimes the only documentation you get from them are the wsdl pages on their server, or maybe they even expect you to have a web-browser on your server to browse the documentation on their web services server. Then you have a problem right? And links/lynx isn’t always web 2.0 enough. Thankfully I recently found this nice Socks feature in OpenSSH. Just connect as follows:

ssh -D 8080 myuser@my.webserver.net

Now when you are logged in, you automatically have a Socks server running at 127.0.0.1:8080. Go to your favourite browser, and go to proxy settings, and enter 127.0.0.1 port 8080 under the “Socks” configuration, and save. Now all your web-browsing is tunneled through your web server, and you can easily open the documentation you wanted.

If you have an application that does not know of Socks proxying, and still want to ‘tunnel’ your data through your remote server, you can of course always use the more known port forwarding functions in OpenSSH (-L, and -R).